<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>1) This sounds good.<BR>2) Can you please apply your analysis to the Win32 version also?<BR> <BR> <BR>Tangentially, I've said both of these before:<BR> <BR> <BR>3) I'd really like to layer the pthread and Win32<BR>versions over a common interface.<BR> <BR> <BR>4) Possibly make it much thinner, if Modula-3 semantics<BR>are close enough to pthread/win32+cv.<BR> <BR> <BR> - Jay<br><br><br> <BR><div>> Date: Mon, 29 Jun 2015 19:18:41 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: hosking@purdue.edu; mika@async.caltech.edu; m3devel@elegosoft.com<br>> Subject: Re: [M3devel] pthread scheduling fairness of Signal<br>> <br>> <br>> <br>> On 06/29/2015 08:53 AM, Antony Hosking wrote:<br>> ><br>> >> On Jun 29, 2015, at 9:40 AM, Rodney M. Bates <rodney_bates@lcwb.coop> wrote:<br>> >><br>> >><br>> >><br>> >> On 06/28/2015 01:16 PM, Antony Hosking wrote:<br>> >>> It mirrors the user-level threads information as far as I recall.<br>> >>><br>> >><br>> >> Do you think that was intentional in the original user-level implementation?<br>> >> It seems like an open invitation to starvation. And it seems even more<br>> >> important for condition variables than mutexen. (hush, spell checker!)<br>> ><br>> > Perhaps take a look at the original user-level implementation to confirm.<br>> > I agree that ideally it would be FIFO. Feel free to think on what is needed to do that.<br>> ><br>> <br>> I looked at ThreadPosix.m3, and indeed it is the same way: FIFO for awakening<br>> Mutex waiters and LIFO for Condition waiters.<br>> <br>> Also, in both thread implementations, the FIFO wakeup is O(n) for a single wakeup.<br>> (n=# of waiting threads.) I think n will most often be quite small, but occasionally,<br>> maybe not, and if/when high thread counts do occur, it would be a good time for things<br>> to be fast.<br>> <br>> It would be quite easy to make both cases FIFO and O(1). No synchronization<br>> changes, just change a few lines of code while holding the same locks that are already<br>> being held.<br>> <br>> If nobody objects, I think I will try this.<br>> <br>> >><br>> >> Mika's high-volume thread tester continuously churns out<br>> >> "Thread <n> appears starved or deadlocked" messages by the hundreds.<br>> >><br>> >>> Sent from my iPad<br>> >>><br>> >>>> On Jun 28, 2015, at 1:58 PM, Rodney M. Bates <rodney_bates@lcwb.coop> wrote:<br>> >>>><br>> >>>> In vetting ThreadPThread in conjunction with the formsedit assertion failure, I<br>> >>>> notice that threads waiting on an M3 MUTEX are awakened in FIFO order, but those<br>> >>>> waiting on an M3 Condition variable are awakened LIFO by Signal. Is this really<br>> >>>> what we want?<br>> >>>> --<br>> >>>> Rodney Bates<br>> >>>> rodney.m.bates@acm.org<br>> >>><br>> >><br>> >> --<br>> >> Rodney Bates<br>> >> rodney.m.bates@acm.org<br>> ><br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br></div> </div></body>
</html>