[M3devel] targeting kernel instead of libc/pthreads?

Tony Hosking hosking at cs.purdue.edu
Tue Aug 11 17:52:30 CEST 2009


On 11 Aug 2009, at 10:57, Dragiša Durić wrote:

> There is exactly one pthreads implementation in use, NPTL.
>
> That is really thin layer providing pthreads API.
>
> I don't think we can afford anything by reimplementing there, but we  
> can
> loose pthreads abstraction.

Agreed, I don't see the win.

> I'we not read Anthony's implementation for some time, but I remember  
> he
> had some state tracking structures resembling earlier behaviour of
> user-space Modula-3 threads. These are not needed,really, except for
> some obscure tools and for at-all-prices compatibility. I don't know  
> if
> it's still there, but if it is, it imposes some non-O(1)-ness, at  
> least
> in Linux case where we have it.

My implementation is much lighter now -- thread state information is  
only ever used for the signal handling needed to suspend/resume thread  
during GC.  Otherwise, no additional accounting in the normal case.   
LOCK is essentially pthread_mutex_lock/unlock.  As far as I recall,  
for purposes of notification (Alert) we still manage wait queues  
explicitly, mostly because the semantics of signals and threads in  
different pthreads implementations varies significantly (I seem to  
remember Dragiša's original approach was sufficient for Linux NPTL,  
but not portable to other platforms).

>
> On Tue, 2009-08-11 at 14:22 +0000, Jay K wrote:
>> I'm aware of that. But I don't think it matches pthreads closely, but
>> provides sufficient primitives. It is clone and futex.
>> I expect the kernel interfaces to be stable and there are multiple,
>> binary incompatible?, pthreads implementations.
>>
>> - Jay
>>
>>
>>> Subject: Re: [M3devel] targeting kernel instead of libc/pthreads?
>>> From: dragisha at m3w.org
>>> To: jay.krell at cornell.edu
>>> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
>>> Date: Tue, 11 Aug 2009 16:14:10 +0200
>>>
>>> Your data is pretty rusty here :)
>>>
>>> pthreads as library is of course "usermode layer over something".
>> That
>>> something being O(1) kernel space thread implementation.
>>>
>>> On Tue, 2009-08-11 at 05:37 +0000, Jay K wrote:
>>>>
>>>> In particular on Linux pthreads are usermode layer over something
>>>> else.
>>> -- 
>>> Dragiša Durić <dragisha at m3w.org>
>>>
> -- 
> Dragiša Durić <dragisha at m3w.org>




More information about the M3devel mailing list