[OpenAFS-devel] Re: pthreading the bosserver

Benjamin Kaduk kaduk@MIT.EDU
Thu, 8 Aug 2013 19:57:51 -0400 (EDT)


On Thu, 8 Aug 2013, Jeffrey Hutzelman wrote:

> On Thu, 2013-08-08 at 16:54 -0400, Benjamin Kaduk wrote:
>
>> Hmm, okay.  I think that the current LWP code and my tree do not have any
>> explicit locking when writing to bnode fields; Chas has a per-bnode lock
>> which protects that state.  I don't remember offhand whether the global
>> lock in my tree can safely be extended to cover such bnode state.  I guess
>> this makes my current CV usage a bit bogus, as it sleeps on the global
>> mutex but is not necessarily using it to protect anything.
>
>
> LWP doesn't need such locks; it's non-preemptive and so only needs
> locking when it yields.

Right, it doesn't have explicit locking because it has implicit locking.

>> Well, that's the use case that I backsolved to from reading the code;
>> maybe Chas had something else in mind.
>> Basically, in things like WaitAll, the code takes the global locks and
>> holds it while copying the allBnode queue to a temporary queue.  It then
>> releases the "main" global lock and holds the "tempq" global lock across
>> the blocking operations that make up the wait in the WaitAll.  The main
>> global lock can't be held like that, as holding it while blocking would
>> tie up all action.  My intuition is telling me that a flag variable
>> protected by the global lock could offer the same protection with less
>> code complexity, but I didn't try to implement such a scheme or analyze it
>> fully.
>
> If you introduce such a thing, then things need to be able to block
> waiting for it, which means you also need to introduce a CV.  That seems

I'm not sure that things will need to be able to block.  Returning BZBUSY 
for BOZO_CreateBnode while we're waiting for shutdown seems fine, to me. 
Maybe there are internal cases which would need to block, but I don't 
remember any off the top of my head.

-Ben

> fine, if you want to go that way.  If you do that, then you probably
> want a third value for the flag that is set when preparing to restart
> the bosserver, so that requests can simply failed instead of blocking on
> an even that's never going to occur.