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.
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
