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.
> with condition variables you do not have to
> do signal with mutex locked to achieve correct
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 ?
> 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
> > 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,
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk