[M3devel] pthread scheduling fairness of Signal

[mika at async.caltech.edu]

Well code shouldn't depend on fairness.  I don't think it's a major issue
if it's backwards.  

I didn't add the warning messages about starved threads to the thread tester.

"Rodney M. Bates" writes:
>
>
>On 06/28/2015 01:16 PM, Antony Hosking wrote:
>> It mirrors the user-level threads information as far as I recall.
>>
>
>Do you think that was intentional in the original user-level implementation?
>It seems like an open invitation to starvation.  And it seems even more
>important for condition variables than mutexen.  (hush, spell checker!)
>
>Mika's high-volume thread tester continuously churns out
>"Thread <n> appears starved or deadlocked" messages by the hundreds.
>
>> Sent from my iPad
>>
>>> On Jun 28, 2015, at 1:58 PM, Rodney M. Bates <rodney_bates at lcwb.coop> wrote
>:
>>>
>>> In vetting ThreadPThread in conjunction with the formsedit assertion failur
>e, I
>>> notice that threads waiting on an M3 MUTEX are awakened in FIFO order, but 
>those
>>> waiting on an M3 Condition variable are awakened LIFO by Signal.  Is this r
>eally
>>> what we want?
>>> --
>>> Rodney Bates
>>> rodney.m.bates at acm.org
>>
>
>-- 
>Rodney Bates
>rodney.m.bates at acm.org