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.