Re: threaded fs'es was Re: native win32 aufs

Hmm you forgot the list :]

----- Original Message -----
From: "Kevin Littlejohn" <darius@bofh.net.au>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Sent: Saturday, March 17, 2001 10:29 PM
Subject: Re: threaded fs'es was Re: native win32 aufs

>
> >>> "Robert Collins" wrote
> > 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 :]
>
> Heh. I picked writes for a reason - for reads, there's an lseek in
there
> before each read (although I'm still not convinced from a read of that
code
> that it'd be thoroughly safe), but not for writes. Still, if I'm
reading this
> right, I would have expected to see more general strangeness for
anyone using
> aufs, so I'm presuming I'm missing _something_. The intervals in
question are
> very small tho, so it's possible we're just lucking out enough?

See my comment on the state machine... Thats where my intuition says the
safety margin is.

> > 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...
>
> Um. Actually, you'd just pthread_mutex_lock() the request_queue lock,
that'd
> return when the lock is unused (ie. when no other thread is removing a
> request). Bearing in mind the "global" nature of the request_queue is
going
> away, that _should_ happen fast.

It means that the control loop (which might have many requests to place
on the queue from the result of the last select() will yield the cpu and
possibly/porbably cause a context switch for no reason. I do think that
the trylock is the more efficient approach, even if it is a little
harder to code.

Henrik? :]

>
> Henrik? :)
>
> KevinL
>
>

Rob
Received on Sat Mar 17 2001 - 04:35:50 MST