[Ecls-list] Mutex & fairness

[Daniel Herring]

On Tue, 27 Mar 2012, Juan Jose Garcia-Ripoll wrote:

> This is tricky. Ideally we should not need any polling at all. The only reason for polling to exist is because we do not have a portable implementation of a wait queue, such as C++'s new eventcount. In other words, we the slow path
> looks like
> 
> 1* try to atomically lock
> 2* enter some brief waiting period which stops on interrupts
> 
> because the signal might be delivered between 1 and 2 and get lost. A possible solution passes through masking the interrupts before 1* and using pthread_sigwait() for 2*, but this gets tricky.

The exact same issue occurs with condition variables.  As a result, the 
caller of pthread_cond_signal frequently needs to use the same mutex as 
the caller of pthread_cond_wait.

Random idea; I don't like it; but maybe it will spark a good one. If ECL 
spawned a dedicated "kernel" process, and other processes sent it messages 
to coordinate scheduling, then each of the other threads could have a 
single dedicated locking mechanism, and lock arbitration would be 
coordinated under a single thread under ECL's control.  So instead of the 
futex "compare-and-swap, then syscall" this would be "compare-and-swap, 
then ask the root thread".

Another idea.  I've seen a people advocate using UNIX sockets as a 
synchronization mechanism in some circumstances.  Write a byte as a 
signal.  The receiving process can use a blocking read() and still be 
woken by interrupts.  Different efficiency tradeoffs than the polling 
loop.  Harder to get lost between 1 and 2, but introducing other problems.


> This is not about improvements, but it is a blocking issue. I have realized that the existing POSIX implementations does not work with Common Lisp users's expectations on interrupts. It is simply impossible to have a thread accept
> interrupts and at the same time use mutexes, because POSIX threads have no way to query whether a mutex is locked or not and pthread_mutex_lock() does not provide a path for existing on the arrival of a signal. In practive this
> leads to a very fair (works nicely with the scheduler) but very unstable implementation.

Can't you use pthread_mutex_trylock to query whether a thread is locked? 
Not super efficient, but it should work.

Similarly, might it be possible to use pthread_mutex_timedlock, and use it 
in a polling loop to check whether any interrupts have been delivered?

In these issues, I sometimes think the user's expectations cannot be 
satisfied, and that they really need something slightly different than 
what they are asking for.  Could you remind me of the thread where this 
interrupt/mutex issue came up?  Is it basically the clean shutdown / 
"Control-C" to wake a hung process issue, or something deeper?

Thanks,
Daniel