This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help for graduate research - how are NLTP routines implemented atthe OS level


Mike, Carlos,

Thanks. I do have one fundamental and probably a very basic question
related to thread creation
calls and the compiler:

How does compiler translate a following line of code into something
that operating system
will recognize as an instruction that will map to an OS thread:

ret_value = pthread_create( &thread1, NULL, print_message_function,
(void*) message1);

I need specifics because this is a graduate level research on compiler
implementations
and I am having problems finding such documentation. I read Drapper's
paper and it does talk
about Futures but the focus is on the OS-level design of the
concurrent data structures not
how compiler interprets and translates PTHREAD API calls.

Thank you in advance,
Edmon


On Wed, Mar 23, 2011 at 8:46 AM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Sat, Mar 19, 2011 at 6:32 PM, Mike Frysinger <vapier@gentoo.org> wrote:
>> On Saturday, March 19, 2011 17:46:18 Edmon Begoli wrote:
>>> I need help understanding what system calls are used to implement
>>> mutexes and context switches.
>>
>> you probably want to google futexes. ?drepper wrote some stuff on it too iirc.
>> try http://people.redhat.com/drepper/
>>
>> in fact, simply googling for "nptl design" shows some good hits.
>>
>>> I am interested in knowing specifically how is pthread_mutex_lock and
>>> unlock implemented and what OS system calls are used for context
>>> switching (longjmp/setjmp?).
>>
>> there arent any syscalls used for context switching, and certainly not
>> setjmp/longjmp. ?the threads are handled by the linux kernel.
>
> Just for some more context.
>
> The Linux kernel and GLIBC have a 1:1 threading model. There are M
> kernel threads that match up with M userspace threads.
>
> Unlike for example, Solaris whose historical default has been an M:N
> implementation where multiple user threads were tied to one kernel
> process, which is scheduled by the kernel.
>
> IIRC anything newer than Solaris 8/9 can use a 1:1 model, and it's is
> the preferred model.
>
> For a whitepaper about the change see:
> http://www.sun.com/software/whitepapers/solaris9/multithread.pdf
>
> Cheers,
> Carlos.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]