>In article <[EMAIL PROTECTED]>, David Greenman
>> >I will add that this is the pattern that Kirk teaches in his kernel
>> >internals class.
>>    If that's true,
>Do you want me to fax you a copy of page 15 of his class notes from
>the course he gave at last year's FreeBSDCon, or will you just take my
>word for it?

   I'm not calling you a liar. I think it is possible that you may have
misunderstood what Kirk was saying, however. Having not been in the class
myself, it is perhaps a bit presumptuous for me to think that. There are
cases where one must check for the condition after the wakeup - the cases
where multiple sleepers/consumers are waiting on the same condition/resource,
for example. ...and there are cases that simply don't work that way and
aren't suseptible to that inherent race condition. Is it possible that
Kirk was speaking about the race condition cases?

>> then he should practice what he preaches. Some of the code that I'm
>> refering to (e.g. lockf) was apparantly written by him.
>Whether Kirk practices what he preaches is irrelevant to this
>discussion.  Instead of focusing on a 1-sentence "I will add ..." from
>my posting, why not respond to the main thrust of it -- the paragraph
>I quoted from the Birrell paper?

   Because I haven't decided whether I agree with it or not. I think an
argument could be made that adding the checks in a case where a bogus
wakeup can never happen might actually obscure the code by leading the
programmer into thinking that there could be multiple sleepers/consumers.
Perhaps I read more into code than I should, but I naturally assume that
if a check is made for something then the condition being checked for
can happen. If it cannot, then that just leads me astray. Certainly
comments are a good thing to keep people on the right path, but then
this applies whether you check the post-tsleep state or not.

>>    I'll say again, however, that some of the cases that rely on the
>> historical symantics would become very expensive if they had to go
>> through a series of complex checks (perhaps list traversals, etc),
>> in order to verify that the wakeup wasn't bogus. I personally don't
>> think this is an improvement.
>Some of them might be expensive, but most of them would not.

   That could be - I honestly don't know and it seems to me that a thorough
code review would be needed before a conclusion can be drawn.

>Obviously the waker-upper knows that the condition is true.  Otherwise
>the existing code which doesn't check wouldn't work.  In the expensive
>cases the waker-upper could simply set a flag for the sleeper to

   For me, that doesn't make the code easier to read or understand - it has
the opposite effect. ...but then I'm used to the historical symantics and
naturally consider the possible cases when looking at the code.

>Note, I am not expressing an opinion about whether the sleeps should
>be terminated prematurely during shutdown.  But I am expressing a
>strong opinion about whether sleepers should do a reality check before

   I could be persuaded to think that way, but I still remain unconvinced.
Again, I'm used to the historical symantics, so changing them requires a
pretty good justification and a bit of brain rewiring, which I naturally


David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
Manufacturer of high-performance Internet servers - http://www.terasolutions.com
Pave the road of life with opportunities.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to