Continuation locking

[Walt Karas]

Why can't the mutexes for continuations simply use test-and-set. We
only ever try to lock them (and requeue the continuation if lock is
not available), correct? Since it's hard to be sure in TS when a
continuation does or does not need a lock, it would be nice if one
could be used defensively with less overhead.

[Alan Carroll]

Because having the locks be recursive is a critical feature due to the tail
recursion used in event handling. And there are places (in other threads)
where blocking locks on Continuations are used.

Post by Walt Karas
Why can't the mutexes for continuations simply use test-and-set. We
only ever try to lock them (and requeue the continuation if lock is
not available), correct? Since it's hard to be sure in TS when a
continuation does or does not need a lock, it would be nice if one
could be used defensively with less overhead.

[Walt Karas]

I don't see the relevance of recursiveness, a non-block lock can be
recursive. What "other threads" do you mean? Are the blocking locks
rare enough that we could implement them with brief usleep() and a
retry?

Because having the locks be recursive is a critical feature due to the tail recursion used in event handling. And there are places (in other threads) where blocking locks on Continuations are used.

Post by Walt Karas
Why can't the mutexes for continuations simply use test-and-set. We
only ever try to lock them (and requeue the continuation if lock is
not available), correct? Since it's hard to be sure in TS when a
continuation does or does not need a lock, it would be nice if one
could be used defensively with less overhead.

--
Beware the fisherman who's casting out his line in to a dried up riverbed.
Oh don't try to tell him 'cause he won't believe. Throw some bread to the ducks instead.
It's easier that way. - Genesis : Duke : VI 25-28