You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally we would like signal to be a blind write, but currently this may induce spurious wakeups in schedulerMainLoop, which would cause the target core to attempt to run a non-existent thread.
One possibility for fixing this is to use some value (all-zeroes) for the function block (storage location for function and arguments of new threads) to indicate that the thread is non-runnable. Under this proposal, schedulerMainLoop will check whether the function block is entirely zeroes after returning from dispatch(). If it is not, then assume it is a spurious wakeup and call continue. Also, on thread exit, before clearing the occupiedAndCount, set the function block to all-zeroes to indicate that the ThreadContext is unoccupied.
This eliminates ThreadContext::UNOCCUPIED and the CAS in signal.
The text was updated successfully, but these errors were encountered:
Ideally we would like
signal
to be a blind write, but currently this may induce spurious wakeups inschedulerMainLoop
, which would cause the target core to attempt to run a non-existent thread.One possibility for fixing this is to use some value (all-zeroes) for the function block (storage location for function and arguments of new threads) to indicate that the thread is non-runnable. Under this proposal,
schedulerMainLoop
will check whether the function block is entirely zeroes after returning fromdispatch()
. If it is not, then assume it is a spurious wakeup and callcontinue
. Also, on thread exit, before clearing theoccupiedAndCount
, set the function block to all-zeroes to indicate that the ThreadContext is unoccupied.This eliminates
ThreadContext::UNOCCUPIED
and theCAS
insignal
.The text was updated successfully, but these errors were encountered: