Re: Async I/O on IRIX 6.x?

From: Andres Kroonmaa <>
Date: Mon, 14 Sep 1998 23:02:50 +0300 (EETDST)

On 13 Sep 98, at 19:16, Alex Rousskov <> 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
 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:
  Network Manager
  Organization: MicroLink Online Tel: 6308 909
  Tallinn, Sakala 19 Pho: +372 6308 909
  Estonia, EE0001 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