On Sun, 2003-09-28 at 01:15, Brandon Low wrote: > Hmm... I just noticed that in the version of your patch that I have at > least, the creator thread can have both countLock and headLock at the > same time, I tried to avoid any one thread grabbing more than one lock > at the same time... is that possible? > > Ahh, I see if we don't synchronize both headLock and countLock we have a > possible NPE we would have to check... disgusting. > That was an embarrassing bug, caused when I inserted the function inline. The return statement would have required a goto (returns are disguised gotos), and I translated it wrongly.
The possible NPE is avoided by ensuring that available is always decremented _before_ unlocking countLock. Then if getThread sneaks in before the synchronize(headLock), and there is only one thread on the stack, getThread won't take it but will create a new thread itself instead. [bug -- see below]. The decision of whether or not to attempt to remove a thread from the stack was being transmitted out of the synchronized section via the return statement, which unlocked but did not dequeue. The prepatch version is I believe correct except for the reference to available in the while condition. My node has been running for 7 hours with the new version, so I'll send it in. Nope. Writing some more comments -- I see that getThread does not decide based on the value of available, as it should. One more bug. Send it in later... > /me ponders I find bugs by writing text about how it works. -- Ed Huff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
