<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
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>
<BR>
<BR>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: hosking@cs.purdue.edu<BR>> Date: Sat, 23 Apr 2011 15:06:22 -0400<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] ease of switching between pthreads and userthreads?<BR>> <BR>> Good point about lock. I really think this is the showstopper because compiled code will be fo a particular threading model. <BR>> <BR>> Sent from my iPhone<BR>> <BR>> On Apr 23, 2011, at 6:19 AM, Jay K <jay.krell@cornell.edu> wrote:<BR>> <BR>> > I've asked before. I'm asking again.<BR>> > <BR>> > <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>> > <BR>> > <BR>> > I'd also like to be able to switch the default via a line in a m3makefile that builds a program.<BR>> > <BR>> > <BR>> > I know roughly what implementing this would look like.<BR>> > <BR>> > <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>> > <BR>> > <BR>> > I'm willing to implement this myself.<BR>> > I'm not asking for anyone else to do it.<BR>> > <BR>> > <BR>> > I understand it makes LOCK harder to efficiently inline.<BR>> > If/when LOCK becomes partly inlined, provide a switch?<BR>> > <BR>> > <BR>> > Thank you,<BR>> > - Jay<BR>> > <BR> </body>
</html>