Well, this makes some sense, although it still seems like this violates
the spirit of condition variables.
Brian W. Barrett wrote:
> 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.
> devel mailing list