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

On Mon, 14 Sep 1998, Henrik Nordstrom wrote:

> True, but those timed condition waits was cheaper than correct
> use of mutexes.

How did you measure? I am interested mostly in the methodology rather than
numbers, because the new [experimental] "correct use of mutexes" differs
from what you have measured. I could try to repeat your measurements to see
if we are on the right track.
 
> The code was designed with a specific purpose; dispatching blocking
> operations on threads, and nothing else. All logic was kept in the
> main thread.

True. That did not change (yet).
 
> > Also, without mutexes, the thread scheduling itself was
> > "unpredictable" as some (all?) pthread man pages suggest.
>
> Not much apart from the sheduling race condition which is not that
> infrequent... ;-)

Well, that sounds scary enough to me. :)
 
> > Defining AIO_PROPER_MUTEX was not a good idea as well because then
> > synchronization became extremely expensive.
>
> On some platforms yes, but what did you do that was less expensive?

I protect the only two shared resources: wait_queue and done_queue (too
mutexes) compared to protecting a request pointer in each thread. wait_queue
requires two mutex operations per request. done_queue requires one mutex
operation for enqueuing a request and one operation for dequeuing all ready
requests. [ Operation is a lock/unlock sequence ]

> * condition variables is the only syncronisation primitive that is
> available on all platforms used platforms.
> * Proper use of condition variables requires locking and unlocking
> of mutexes when signalling the condition to avoid the scheduling
> race condition you refer to, as condition variables are unbuffered.

Right. Fortunately, that is done while enqueueing a request (no extra locks
to the ones described above).

> Multiple syncronisation variables was selected from the assumtion
> that the main thread may need to activate more than one thread
> before giving up the CPU,

My implementation supports that.

> and that it is the number of mutex
> locks/unlocks that is important and not the number of mutexes.

Sure. However, having less mutexes never hurts :)

Alex.

P.S. I should probably try disabling mutexes to see if it improves the
performance. I hope it does not.
Received on Tue Jul 29 2003 - 13:15:53 MDT