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

On Mon, 14 Sep 1998, Andres Kroonmaa wrote:

> By reducing mutexes you might increase a chance of contention. Just keep in mind.

I will. However, I find statements like "having more mutexes never hurts"
extremely speculative. If I have a choice of maintaining 2 objects and 100
objects, I would at least try the first alternative first.

There is also a theory that 8-lane highways create more traffic jams than
4-lane ones, given the same amount of traffic. Go figure.

In short, I do not think that counting mutexes is a good performance
predictor. A lot of things depend on the way those mutexes are actually used.

With one mutex per thread one ends up polling all threads with
"are-you-busy?" question. If that question is protected by a mutex, the
polling becomes expensive. And there is always a chance of missing an idle
thread behind, regardless of the mutex use.

With one mutex per queue, no polling is necessary and no idle threads are
ever missed. One can call it "academic". I do not care, as long as it looks
good and works well.

> hmm, why you consider timed cond_wait more expensive than plain cond_wait?

In my academic point of view, "doing A and B" is always more expensive than
"doing A". Especially if "B" involves timing. I cannot quantify the
difference. I bet it depends on the number of threads and their waiting
patterns. I know for sure that "3 seconds wait" does happen.

> > Also, without mutexes, the thread
> > scheduling itself was "unpredictable" as some (all?) pthread man pages
> > suggest.
>
> It is this way anyway...

That's not what the man pages say though. Perhaps you know better.

> And trying to lock locked mutex means mutex contention, the very first thing
> to avoid in MT code. In this sense: predictable ~= inefficient ;)

What if there is often no contention when I am locking the mutex? What if
the right (predictable) order of thread execution makes other optimizations
possible?

 
Thank you,

Alex.
Received on Tue Jul 29 2003 - 13:15:54 MDT