[M3devel] ease of switching between pthreads and userthreads?

[Tony Hosking]

On Apr 27, 2011, at 3:05 AM, Jay K wrote:

> About inlining LOCK I was more echoing your past sentiment
> than giving my own, and I provided a mitigation:
>  a) specifically the suggestion that the switchability be an option;
>   it'd probably be on by default but people that want to squeeze
>   out the extra performance could enable the inlining
>   and lose the switchability

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110427/d4f20090/attachment-0002.html>