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

On 14 Sep 98, at 14:38, Alex Rousskov <rousskov@nlanr.net> wrote:

> 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.
  ^^^^^ Thats the most point. It all depends...
 
> 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.

 Of course. mutex always reduces performance. the only thing many mutexes can
 give you, is possibly parallelism. Definitely you cannot place mutexes here
 and there blindly and hope for best ;)

> 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.

 try_lock is not expensive, as it cannot initiate thread switch, because it has
 to return the current state of a "try".

> 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.

 And how do you signal threads?

> > 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.

 I agree, this 3 sec is not nice. I just don't know your solution to the problem.
 
> > > 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.
 what pages?
> Perhaps you know better.
 not necessarily ;)
 
> > 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?

 Then go for it ;)
 But keep in mind that every mutex op can cause a thread switch, and as squid
 benefits only from kernel threads, then that means a context switch.
 Unlocking crowdy mutex can cause many thread switches and mutex spins.

 PS. Isn't it strange. I was the most opponent for Stew's design, and now find
 myself mostly defending its benefits? :) It just seems to me that to change the
 design now you most probably would need to through out most of stew's design,
 and that's pity, its so cute, I've been almost always amused it worked at all ;))

 ----------------------------------------------------------------------
  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