This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Thu, 6 Dec 2007, Tim Prins wrote:
> Tim Prins wrote:
>> First, in opal_condition_wait (condition.h:97) we do not release the
>> passed mutex if opal_using_threads() is not set. Is there a reason for
>> this? I ask since this violates the way condition variables are supposed
>> to work, and it seems like there are situations where this could cause
> So in (partial) answer to my own email, this is because throughout the
> code we do:
> opal_condition_wait(cond, m);
> So this relies on opal_condition_wait not touching the lock. This
> explains it, but it still seems very wrong.
Yes, this is correct. The assumption is that you are using the
conditional macro lock/unlock with the condition variables. I personally
don't like this (I think we should have had macro conditional condition
variables), but that obviously isn't how it works today.
The problem with always holding the lock when you enter the condition
variable is that even when threading is disabled, calling a lock is at
least as expensive as an add, possibly including a cache miss. So from a
performance standpoint, this would be a no-go.
>> Also, when we are using threads, there is a case where we do not
>> decrement the signaled count, in condition.h:84. Gleb put this in in
>> r9451, however the change does not make sense to me. I think that the
>> signal count should always be decremented.
>> Can anyone shine any light on these issues?
Unfortunately, I can't add much on this front.