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
make
> > 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,
Vitalij.