<html><head><base href="x-msg://839/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>
<br><div><div>On Apr 27, 2011, at 3:05 AM, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">About inlining LOCK I was more echoing your past sentiment<br>than giving my own, and I provided a mitigation:<br> a) specifically the suggestion that the switchability be an option;<br> it'd probably be on by default but people that want to squeeze<br> out the extra performance could enable the inlining<br> and lose the switchability<br></div></span></blockquote><div><br></div><div>It is expected that LOCK will be implemented using CAS (and equivalents) in the very near future. I have a student working on it. This will be incompatible with the current user-threads implementation of LOCK. It will be too painful to support both using a compiler switch.</div><br><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; "> About the need to link to pthread.<br>Good point. I hadn't thought of that.<br>BUT two points in possible rebuttal (not that is necessary<br>an argument! more like a conversation)<br>I'm sure that on some platforms there is no distinction.<br>No separate broken libc.so and working libpthread.so.<br>But yes, I realize the recent talk was about Linux, apparently it is broken.<br>Solaris is probably better.<br>Others I don't know, I'd have to check.<br> <br><br>Specifically, there should not be two separate fork implementations.<br>Or two separate malloc implementations.<br> <br><br>The one and only fork must know about pthread_atfork.<br>The one and only malloc must be thread safe, with respect to pthreads.<br> (but not necessarily Modula-3 user-threads, that is our own problem).<br> <br><br>If that means fork and pthread_atfork have to be in the same .so,<br>and/or that malloc and pthread_* have to be in the same .so, both<br>of which are easy to believe are true, so be it.<br> <br><br>I shouldn't get one malloc via cc foo.c and a different<br>one via cc foo.c -lpthread.<br>The rare single-threaded process isn't worth optimizing.<br>Isn't worth the headache.<br> <br><br>As well, though..and this isn't trivial, but I wonder if we should<br>dispense with "static dynamic" linking, where we just call fork, malloc, etc.,<br>but instead use "dynamic dynamic" ie. using dlopen/dlsym aggressively.<br>That might address some of this libc vs. libpthread problem?<br>But then the ABI rather than the source interface becomes needed to be known.<br>Possibly a problem..or possibly it is easy and direct with nothing tricky in most of the headers...?<br> <br><br>Hm. No. Nevermind.<br>What is the problem again with using -pthread on Linux with user threads?<br>So, maybe it pulls in an extra .so and has some small startup cost.<br>Surely it should work?<br>I'll have to dig in to the email and reproduce the bug.<br>I'm of a mind now to remove the recent pthread_atfork stuff.<br>But first I or someone has to understand the problem I was solving.<br>Right now, I don't.<br> <br><br>The LOCK inlining problem seems very hypothetical right now.<br>We don't have such a feature. Will we really ever?<br><br> <br>Is pthread_lockmutex partially inlined in C?<br>Or have pthreads generally been implemented well enough that everyone is satisfied<br>with no inlining?<br><br> <br>Or does Modula-3 sort of promote threads as lighter weight than they are<br>in typical practise? And ditto for locking?<br><br> <br>You know, 15+ years ago when Modula-3, Win32, I suspect Solaris,<br>I suspect all the commercial Unices, had already presented and reasonably<br>implemented the ideal threading interface, but all the free Unices were still<br>holding out and either not providing pthreads or not providing them well..<br>at the time Modula-3 was slightly ahead of its time, and one could imagine<br>not using the underlying platform directly because it was too slow<br>or not full featured enough. But hasn't everything just about caught up by<br>now (except OpenBSD with its user pthreads...)<br>(Yeah...15 years ago, Solaris was probably still a bit wonky..more like 6<br>years ago circa Solaris 2.10 was pretty modern..)<br> <br><br>That is -- are pthreads really worth us optimizing beyond?<br>Don't all the C and C++ programmers and systems providers get it by now<br>and have provided almost exactly what we need?<br> <br> <br>Sorry, I'm rambling...<br> <br><br>Later,<br> - Jay<br><br> <br>> From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>> Date: Sat, 23 Apr 2011 15:06:22 -0400<br>> To:<span class="Apple-converted-space"> </span><a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>> CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: Re: [M3devel] ease of switching between pthreads and userthreads?<br>><span class="Apple-converted-space"> </span><br>> Good point about lock. I really think this is the showstopper because compiled code will be fo a particular threading model.<span class="Apple-converted-space"> </span><br>><span class="Apple-converted-space"> </span><br>> Sent from my iPhone<br>><span class="Apple-converted-space"> </span><br>> On Apr 23, 2011, at 6:19 AM, Jay K <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br>><span class="Apple-converted-space"> </span><br>> > I've asked before. I'm asking again.<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > I'd like to be able to switch between userthreads and pthreads via a command line switch to the executable.<br>> > @M3pthreads @M3userthreads<br>> > or somesuch.<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > I'd also like to be able to switch the default via a line in a m3makefile that builds a program.<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > I know roughly what implementing this would look like.<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > I am a bit confused as to what problems -pthread/-pthreads/-lpthread causes.<br>> > I'll have to reread.<br>> > Whatever problem it has, this change probably would too.<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > I'm willing to implement this myself.<br>> > I'm not asking for anyone else to do it.<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > I understand it makes LOCK harder to efficiently inline.<br>> > If/when LOCK becomes partly inlined, provide a switch?<br>> ><span class="Apple-converted-space"> </span><br>> ><span class="Apple-converted-space"> </span><br>> > Thank you,<br>> > - Jay<br>> ><span class="Apple-converted-space"> </span><br></div></span></blockquote></div><br></body></html>