modern-multithreading-c-java

class Consumer : public Thread { public:

virtual void* run () { int result;

std::cout << "consumer running" << std::endl; for (int i=0; i<2; i++) {

fullSlots.P();

mutexW.lock();

result = sharedBuffer.withdraw(); mutexW.unlock();

std::cout << "Consumed: " << result << std::endl; emptySlots.V();

}

return 0;

}

};

int main() {

std::auto_ptr<Producer> p1(new Producer); std::auto_ptr<Producer> p2(new Producer); std::auto_ptr<Consumer> c1(new Consumer); std::auto_ptr<Consumer> c2(new Consumer); p1->start();c1->start(); p2->start();c2->start(); p1->join(); p2->join(); c1->join(); c2->join(); return(0);

}

Listing 3.26 (continued )

3.8.1 Mutex

A Pthreads mutex is a lock with behavior similar to that of a Win32 CRITICAL SECTION. Operations pthread mutex lock() and pthread mutex unlock() are analogous to EnterCriticalSection() and LeaveCriticalSection(), respectively:

žA thread that calls pthread mutex lock() on a mutex is granted access to the mutex if no other thread owns the mutex ; otherwise, the thread is blocked.

žA thread that calls pthread mutex lock() on a mutex and is granted access to the mutex becomes the owner of the mutex.

žA thread releases its ownership by calling pthread mutex unlock(). A thread calling pthread mutex unlock() must be the owner of the mutex.

ž There is a conditional wait operation pthread mutex trylock (pthread mutex t* mutex) that will never block the calling thread. If the mutex is currently locked, the operation returns immediately with the error code EBUSY. Otherwise, the calling thread becomes the owner.

Listing 3.27 shows how to use a Pthreads mutex. You initialize a mutex by calling the pthread mutex init() function. The first parameter is the address of the mutex. If you need to initialize a mutex with nondefault attributes, the second parameter can specify the address of an attribute object. When the mutex is no longer needed, it is destroyed by calling pthread mutex destroy().

When you declare a static mutex with default attributes, you can use the PTHREAD MUTEX INITIALIZER macro instead of calling pthread mutex int(). In Listing 3.27, we could have written

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

You do not need to destroy a mutex that was initialized using the PTHREAD MUTEX INITIALIZER macro.

By default, a Pthreads mutex is not recursive, which means that a thread should not try to lock a mutex that it already owns. However, the POSIX 1003.1 2001 standard allows a mutex’ s type attribute to be set to recursive:

pthread_mutex_t mutex; pthread_mutexattr_t mutexAttribute;

int status = pthread_mutexattr_init (&mutexAttribute); if (status !=0) { /* ... */ }

status = pthread_mutexattr_settype(&mutexAttribute, PTHREAD_MUTEX_RECURSIVE);

if (status != 0) { /* ... */}

status = pthread_mutex_init(&mutex,&mutexAttribute); if (status != 0) { /* ... */ }

If a thread that owns a recursive mutex tries to lock the mutex again, the thread is granted access immediately. Before another thread can become the owner, an owning thread must release a recursive mutex the same number of times that it requested ownership.

3.8.2 Semaphore

POSIX semaphores are counting semaphores. Operations sem wait() and

sem post() are equivalent to P() and V(), respectively. POSIX semaphores have the following properties:

žA semaphore is not considered to be owned by a thread—one thread can execute sem wait() on a semaphore and another thread can execute sem post().

žWhen a semaphore is created, the initial value of the semaphore is specified. The initial value must be greater than or equal to zero and less than or equal to the value SEM VALUE MAX.

// Wait for threads to finish

status = pthread_join(threadArray[0],NULL); if (status != 0) { /* ... */}

status = pthread_join(threadArray[1],NULL); if (status != 0) { /* ... */}

// Destroy mutex

status = pthread_mutex_destroy(&mutex); if (status != 0) { /* ... */ }

}

Listing 3.27 (continued )

žSemaphore operations follow a different convention for reporting errors. They return 0 for success. On failure, they return a value of −1 and store the appropriate error number into errno. We use the C function perror(const char* string) to transcribe the value of errno into a string and print that string to stderr.

žThere is a conditional wait operation sem trywait (sem t* sem) that will never block the calling thread. If the semaphore value is greater than 0, the value is decremented and the operation returns immediately. Otherwise, the operation returns immediately with the error code EAGAIN indicating that the semaphore value was not greater than 0.

Listing 3.28 shows how Pthreads semaphore objects are used. Header file <semaphore.h> must be included to use the semaphore operations. Semaphores are of the type sem t. A semaphore is created by calling the sem init() function. The first argument is the address of the semaphore. If the second argument has a nonzero value, the semaphore can be shared between processes. With a zero value, it can be shared only between threads in the same process. The third argument is the initial value. When the semaphore is no longer needed, it is destroyed by calling sem destroy().

We can create a simple C++ class that wraps POSIX semaphores, just as we did with Win32 semaphores. Listing 3.29 shows wrapper class POSIXSemaphore. The methods of PthreadSemaphore forward calls to the corresponding POSIX semaphore functions. To assist with testing and debugging, we’ll need user-level lock and semaphore classes like the ones we developed for Win32. We can use POSIXSemaphore to implement both of these classes. The code for C++/Pthreads classes mutexLock and countingSemaphore is identical to the code in Listings 3.23 and 3.24, respectively, except that class win32Semaphore should be replaced by class POSIXSemaphore. The difference between Win32 and POSIX is encapsulated in the semaphore classes.

//initialize semaphore s status = sem_init(&s,0,1); if (status !=0) {

std::cout << __FILE__ << ":" << __LINE__ << "- " << flush; perror("sem_init failed"); exit(status);

}

//initialize the thread attribute object

status = pthread_attr_init(&threadAttribute);

if (status != 0) { /* see Listing 1.4 for Pthreads error handling */} // set the scheduling scope attribute

status = pthread_attr_setscope(&threadAttribute, PTHREAD_SCOPE_SYSTEM);

if (status != 0) { /* ... */}

// Create two threads and store their IDs in array threadArray

status = pthread_create(&threadArray[0], &threadAttribute, Thread1, (void*) 1L);

if (status != 0) { /* ... */}

status = pthread_create(&threadArray[1], &threadAttribute, Thread2, (void*) 2L);

if (status != 0) { /* ... */}

status = pthread_attr_destroy(&threadAttribute); // destroy the attribute object if (status != 0) { /* ... */}

// Wait for threads to finish

status = pthread_join(threadArray[0],NULL); if (status != 0) { /* ... */}

status = pthread_join(threadArray[1],NULL); if (status != 0) { /* ... */}

// Destroy semaphore s status = sem_destroy(&s); if (status !=0) {

std::cout << __FILE__ << ":" << __LINE__ << "- " << flush; perror("sem_destroy failed"); exit(status);

}

}

Listing 3.28 (continued )

3.9 ANOTHER NOTE ON SHARED MEMORY CONSISTENCY

Recall from Section 2.5.6 the issues surrounding shared memory consistency. Compiler and hardware optimizations may reorder read and write operations on shared variables, making it difficult to reason about the behavior of multithreaded

The purpose of nondeterministic testing is to exercise as many distinct program behaviors as possible. Unfortunately, experiments have shown that repeated executions of a concurrent program are not likely to execute different behaviors [Hwang et al. 1995]. In the absence of significant variations in I/O delays or network delays, or significant changes in the system load, programs tend to exhibit the same behavior from execution to execution. Furthermore, the probe effect (see Section 1.7), which occurs when programs are instrumented with debugging code, may make it impossible for some failures to be observed.

There are several techniques we can use to increase the likelihood of exercising different behaviors. One is to change the scheduling algorithm used by the operating system (e.g., change the value of the time quantum that is used for round-robin scheduling). However, in many commercial operating systems this is simply not an option. The second technique is to insert Sleep(t) statements into the program with the sleep amount t randomly chosen. Executing a Sleep statement forces a context switch and thus indirectly affects thread scheduling. We have implemented this second technique as an execution option for programs that use the binarySemaphore, countingSemaphore, and mutexLock classes in our synchronization library. When this option is specified, Sleep statements are executed at the beginning of methods P(), V(), lock(), and unlock(). The Sleep time is randomly chosen within a programmable range. The random delays can be used in conjunction with the tracing and replay functions so that any failures that are observed can also be replayed.

To detect data races, we combine nondeterministic testing with the lockset algorithm [Savage et al. 1997]. The lockset algorithm checks that all shared variables follow a consistent locking discipline in which every shared variable is protected by a lock. Since there is no way of knowing which locks are intended to protect which variables, we must monitor the executions and try to infer a relationship between the locks and variables. For each variable, we determine if there is some lock that is always held whenever the variable is accessed.

For shared variable v, let the set CandidateLocks(v) be those locks that have protected v during the execution so far. Thus, a lock l is in CandidateLocks(v) if, during the execution so far, every thread that has accessed v was holding l at the moment of the access. CandidateLocks(v) is computed as follows:

žWhen a new variable v is initialized, its candidate set is considered to hold all possible locks.

žWhen v is accessed on a read or write operation by T, CandidateLocks(v) is refined. The new value of CandidateLocks(v) is the intersection of CandidateLocks(v) and the set of locks held by thread T.

Based on this refinement algorithm, if some lock l protects v consistently, it will remain in CandidateLocks(v) as CandidateLocks(v) is refined. If CandidateLocks(v) becomes empty, it indicates that there is no lock that protects v consistently. Following is the lockset algorithm: