At 8:56 PM -0600 9/4/03, Luke Palmer wrote:
Gordon Henriksen writes:
What you're suggesting also has significant side-effects: It halts hypothetical multithreaded programs, suspends DoD, prevents the traversal mechanism from calling back into parrot code, requires fine-grained locks which are extremely expensive and have been summarily abandoned to great acclaim in all prior works... and for that, still doesn't provide a useful form of thread safety in the general case anyhow.
Is there a problem with providing a mechanism which would suspend all threads except for the "current" one, as to ensure that the serialize operates, er, serially. Could it be implemented with a top-priority event post that acquires a global lock?
The biggest problem with a lock of this sort is that it requires all the interpreters to actually *check* it to be meaningful. (Not that there aren't other problems--there are, quite a number of them--but this is the big one) Locks nobody gets aren't useful, and for this one to be useful we'd need to have some assurance that the other threads were looking at it regularly, and that those threads were all paused when we wanted to do our stuff.
You end up with either long delays waiting, or a lot of contention on a single global lock. Neither is particularly good.
I think Luke wasn't suggesting a global lock, but rather suggesting that the competing threads be suspended using operating system facilities to temporarily prevent them from being scheduled.
—
Gordon Henriksen [EMAIL PROTECTED]
