Information Technology Reference
In-Depth Information
the system call will return with the value
EINTR
if the threadreceives a
signal.
A call to
longsysfutex(void*addr1,FUTEXWAKE,1,NULL,NULL,
0)
causes one thread waiting on
addr1
to return.
Consider the following (too) simple implementation of a hybrid user-
level/kernel-level lock.
classTooSimpleFutexLock{
private:
intval;
public:
TooSimpleMutex():val(0){}
//Constructor
voidAcquire(){
intc;
while((c=atomic_inc(val))!=0){
//atomic_increturns*old*value
futex_wait(&val,c+1);
}
}
voidRelease(){
val=0;
futex_wake(&val,1);
}
};
There are three problems with this code.
(a.) Peformance. The goal of this code is to avoid making (expensive)
system calls in the uncontested case when an Acquire() tries to ac-
quire a free lock or a
Release()
call releases a lock with no other
waiting threads. This code fails to meet this goal. Why?
(b.) Performance. There is a subtle corner case when multiple threads
try to acquire the lock at the same time that can show up as occa-
sional slowdowns and bursts of CPU usage. What is the problem?
(c.) Correctness. There is a corner case that can cause the mutual
exclusion correctness condition to be violated, allowing two threads
to both believe they hold the lock. What is the problem?
5.6
Designing and implementing shared objects
Although multi-threaded programming has a reputation for being dicult, shared
object provide a basis for writing simple, safe code for multi-threaded programs.
In this section, we first define a high-level approach to designing shared objects.
Then, we define some specific rules that you should follow when you implement
them. Our experience is that following this approach and these rules makes it
