Boost logo

Boost :

From: flameframe_at_[hidden]
Date: 2001-08-13 09:22:50

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> > - some lock in my code requires
> > lock/unlock mutex + set event call
> > - in Programming with POSIX Threads
> > lock/unlock mutex + CV management
> >
> > I am by no means a threading expert but from the above I can not
> > deduction that event's price is higher.
> your code does require set/reset to be done with
> mutex locked to achieve correct behavior.

Yes. Exactly.

> with condition variables you do not have to
> do signal with mutex locked to achieve correct
> behavior

Nice that I have not to do something :-). But I do not see an
advantage in just a different program flow.

> (actually, signalling after mutex.unlock
> should result in more efficient execution)..

Is it just a supposal or a result of a real experience ?

> it
> has some special meaning, however. on uniprocessor
> with priority scheduling you could achieve predictable
> scheduling doing signaling with mutex locked. that is
> what "hard-realtime" applications sometime really need..

As I can understand it says in favour of my code, isn't ?

> > Anyway, I have mentioned event-based solutions just to object
that it
> > always result either to race conditions or to CV-equivalent.
> well, i think it does ;) WaitForMultiple( mutex,event...)
> is a sort of inefficient monitor which should better be
> implemented as CV-based "equivalent" (another solution
> could be based on SignalAndWait "equivalent" but then you
> would have a problem with respect to win32 thread suspension,
> etc..).
> regards,
> alexander.

What do you mean with 'inefficient'? I will be really glad to change
my threading code to something more efficient but, as I have already
asked, - do you have real time comparision results between two models
or it is just your feeling?

Best regards,

Boost list run by bdawes at, gregod at, cpdaniel at, john at