Re: [boost] Problem with conditional variables in boost

From: Mariusz Kedzierawski (m.kedzierawski_at_[hidden])
Date: 2006-09-29 05:46:42

Hi

> What is OS20?

Its operating system from STMicroelectronics designed & implemented
for their chips.

> If you do have a pthread library, I recommend using this instead, since
> the implementation of condition variables contains a lot of traps.

Unefortunatelly I don't have pthreads on OS20. I know implementation
of synchronizing primitives is very tricky, thats why I haven't
started to write one by myself. I picked up boost code which I assume
is well designed/implemented/tested. I just have to replace mutex/sem
calls to that I have on os20. But traps you are talking about means
that boost implementation for example for win is not error free and
have well known flaws ? :)

While analyzing conditionals impl. for win I found myself with more questions:

Like I said earlier, unlocking a mutex and hanging on sem should be atomic. In

template <typename M> void condition::do_wait(M& mutex)....

however it is not. Doesn't that mean that we can miss notification between

lock_ops::unlock(mutex, state);

and

m_impl.do_wait();

and possibly lock forever on sem ?

I must admit that I don't fully understand all code from
conditional.cpp. Its somewhat twisted, especially m_gone var. usage
for example in function:

void condition_impl::do_wait()

there is a line:

else if (++m_gone == ((std::numeric_limits<unsigned>::max)() / 2))

which checks if m_gone reached halfway to unsigned max value...

Another question: since m_gone is handled in non timed waiting
routine: do_wait() does it mean that I can use on single conditional
object both: timed and infinitive waiting and it just works ? On OS20
for example there are separate mutex/sem object types for timed/inf.
waiting.

-- 
Mariusz Kêdzierawski
M(dot)Kedzierawski_at_[hidden]