threads1

threads1 - To create a thread, one calls the pthread_create...

Info iconThis preview shows pages 1–7. Sign up to view the full content.

View Full Document Right Arrow Icon
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
To create a thread, one calls the pthread_create routine. This skeleton code for a server application creates a number of threads, each to handle client requests. If pthread_create returns successfully (i.e., returns 0), then a new thread has been created that is now executing independently of the caller. This new thread has an ID that is returned via the first parameter. The second parameter is a pointer to an attributes structure that defines various properties of the thread. Usually we can get by with the default properties, which we specify by supplying a null pointer (we discuss this in more detail later). The third parameter is the address of the routine in which our new thread should start its execution. The last argument is the argument that is actually passed to the first procedure of the thread. If pthread_create fails, it returns a code indicating the cause of the failure.
Background image of page 2
An obvious limitation of the pthread_create interface is that one can pass only a single argument to the first procedure of the new thread. In this example, we are trying to supply code for the rlogind example of the previous module, but we run into a problem when we try to pass two parameters to each of the two threads. A further issue is synchronization with the termination of a thread. For a number of r ea
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
To pass more than one argument to the first procedure of a thread, we must somehow encode multiple arguments as one. Here we pack two arguments into a structure, then pass the pointer to the structure. This technique at least does not produce any compile- time errors, but it has a potential serious problem.
Background image of page 4
In the previous example, the in and out structures are local variables of the “mainline” thread. Their addresses are passed to new threads. If the mainline thread returns from its rlogind procedure before the new threads terminate, there is the danger that the new threads may dereference their argument pointers into storage locations that are no longer active. This would cause a serious runtime problem that might be difficult to track down. However, if we can guarantee that the mainline thread does not return from rlogind until after the new threads have terminated, then our means for passing multiple arguments is safe. In the example above, the mainline thread places calls to pthread_join ,wh ichdoes not return until the thread mentioned as its first argument has terminated. Thus the
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
A thread terminates either by calling pthread_exit or by returning from its first procedure. In either case, it supplies a value that can be retrieved via a call (by some other thread) to pthread_join . The analogy to process termination and the waitpid system call in Unix is tempting and is correct to a certain extent—Unix’s wait ,l ike pthread_join ,letsone
Background image of page 6
Image of page 7
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 12/03/2010 for the course CS 168 taught by Professor Jj during the Spring '10 term at Brown.

Page1 / 48

threads1 - To create a thread, one calls the pthread_create...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online