[M3devel] ease of switching between pthreads and userthreads?

[Jay K]

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
 

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/d125c693/attachment-0002.html>