Re: native win32 aufs

----- Original Message -----
From: "Kevin Littlejohn" <darius@bofh.net.au>
To: <squid-dev@squid-cache.org>
Sent: Saturday, March 17, 2001 9:55 PM
Subject: Re: native win32 aufs

>
> >>> "Robert Collins" wrote
> >
>
> Ok, fair enough. Next question: How does the existing code deal with
keeping
> order on requests? I've been trying to determine how it stops itself
from,
> for example, executing write requests out-of-order - it looks to me
like
> there's nothing that explicitly ensures order is maintained, it's more
relying
> on order generally working. That's probably my blindness, but I want
to
> check...

Well I'd guess that the writes have a file offset they're writing to: so
why does it matter? The kernel mode fs will take care of it. Also squid
by it's core state machine will not put two write requests for a single
file in the quere (or will it?) I haven't really studied this code and
should probably stop commenting :]

> > AFAICT It's so squid doesn't block when queueing the request. The
point
> > is that the main request queue gets locked via the mutex when a
thread
> > is removing an item from the queue. The control thread therefore
needs
> > to store the item somewhere.
>
> Is it not acceptable to make the locking times as short as possible,
and let
> the control thread wait? I mean, a lock/change a pointer/unlock
sequence should
> be fast enough that it doesn't bother the control thread
significantly, no?
> Certainly, that time will still be shorter than the time the control
thread waits
> in the case of non-async ufs... ;)

Well lets say I have 10 disks, with 16 threads each. That's up to a 160
times I might have to repeat that timed wait to get a lock. There are
probably better aproachs out there... but I'm new to coding multi
threaded apps vs reading and thinking about em, so again I'll defer to
the gurus...

Rob
Received on Sat Mar 17 2001 - 04:04:59 MST