[OpenAFS-devel] Re: pthreading the bosserver

[Jeffrey Hutzelman]

On Thu, 2013-08-08 at 16:54 -0400, Benjamin Kaduk wrote:

> >> Second, how strong of an integrity guarantee do we need for the bos
> >> config?  My understanding is that configuration changes (adding or
> >> removing or en/disabling bnodes) are rare events, and it is highly
> >> unlikely that multiple administrator connnections changing things will
> >> be made concurrently.
> >
> > We can assume they are infrequent, but we must assume that they will
> > happen. That is, there needs to be locking, but it doesn't need to be
> > very granular. That is, it can be slow, but it cannot cause something to
> > break or behave weirdly.
> 
> 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.


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



I think I'm fine with dropping Linux 2.4 support in all of our servers.

-- Jeff