On 13 Sep 98, at 19:16, Alex Rousskov <rousskov@nlanr.net> wrote:
> > > We have done some steps in the direction of (a). For example, the code I am
> > > testing now has only two mutexes (compared to one per thread) and much
> > > cheaper communication between the main thread and other threads.
Please note that zillions of mutexes is for good, not for bad. Too few mutexes
might or might not become a bottleneck, depending on traffic patterns, just like
single-lane pass on a highway may or may not become a bottleneck depending on
traffic.
There is no performance penalty with a mutex as long as there is no contention.
That is, locking free mutex is cheap, only resolving mutex contention is expensive.
By reducing mutexes you might increase a chance of contention. Just keep in mind.
> > Could you elaborate on this? I have a hard time beleiving you would get
> > a more efficient implementation by using less mutexes. Especially if
> > you keep in mind that the old code did not use the mutexes at all..
> > (unless AIO_PROPER_MUTEX is defined)
>
> Right, except that with AIO_PROPER_MUTEX undefined threads where using
> expensive "timed" condition wait, and one could hardly add anything to the
> code without running into race conditions.
hmm, why you consider timed cond_wait more expensive than plain cond_wait?
AFAIK, timed wait was introduced after avoiding extra mutex_lock before
signalling a thread as it could introduce a chance of thread lockup.
Therefore a timeout. In any case, to me it seems stew considered extra
mutex lock (frequent) more expensive than a timed wait.
> Also, without mutexes, the thread
> scheduling itself was "unpredictable" as some (all?) pthread man pages
> suggest.
It is this way anyway... You can only predict that if you try to lock a mutex
held by another thread, you get a context switch. And that if you signal a
thread blocked on cond_wait, it is placed at the tail of a run queue.
Thats about all thats predictable.
And trying to lock locked mutex means mutex contention, the very first thing
to avoid in MT code. In this sense: predictable ~= inefficient ;)
> Defining AIO_PROPER_MUTEX was not a good idea as well because then
> synchronization became extremely expensive.
----------------------------------------------------------------------
Andres Kroonmaa mail: andre@online.ee
Network Manager
Organization: MicroLink Online Tel: 6308 909
Tallinn, Sakala 19 Pho: +372 6308 909
Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------
Received on Tue Jul 29 2003 - 13:15:54 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:11:55 MST