Os-tep:fetch-and-add

One final hardware primitive is the fetch-and-add instruction, which atomically increments a value while returning

The old value at a partucular address. The C presudocode for the fetch-and-add instruction looks like this:

int Fetchandadd (int* ptr) {         int old = *ptr;         *ptr = old + 1;         return old;}

In this example, we'll use Fetch-and-add to build a more interesting ticket lock, as instroduced by Mellor-crummey

and Scott. The lock and unlock looks like "What's in following" figure.

typedef struct __LOCK_T {           int ticket;           int turn;} Lock_t;void Lock_init (lock_t* lock) {           lock->ticket = 0;           Lock->turn   = 0;} void Lock (lock_t* lock) {           int myturn = Fetchandadd (&lock->ticket);           while (Lock->turn = = Myturn)                    ;} void unlock (lock_t* lock) {           Lock->turn = Lock->turn + 1;}

Instead of a signal value, this solution uses a ticket and Tuen variable in combination to build a lock. The basic operation

is pretty simple:when a thread wishes to build a lock, it first does a atomic fetch-and-add on the ticket value; That

Value is now considered this thread ' s turn. The globally shared Lock->turn is then used to determine which thread ' s

Turn it is; When Myturn = = turn for a given thread, it's that thread's turn to enter the critical section. Unlock is accomplished

Simply by incrementing the turn such that the next waiting thread (if there was one) can now enter the critical section.

Note One important difference with this solution versus we previous attempts:it ensures progress for all threads. Once

A thread is assigned it ticket value, it'll be scheduled at some point in the future (once these in front of it has PA ssed

Through the critical section and released the lock). In our previous attempt, no such guarantee existed; A thread

Spining on Test-and-set (for example) could spin forever even as other threads acquire and release the lock.

Too Much spinning:what now?

Our simple hardware-based locks is simple (only a few lines of code) and they work (your could even prove that

If you would like to, by writing some code), which is both excellent properties of any sytem or code. However, in

Some cases, these solutions can be quite inefficient. Imagine you is running, threads on a and processor.

Now imagine this one thread (thread 0) is in a critical section and thus have a lock held, and unfortunately gets

Interrupted. The second thread (thread 1) now tries to acquire the lock, but finds this it is held. Thus, it begins to

Spin. and spin. Then it spins some mroe. And finally, a timer interrupt goes off, thread 0 is run again, which releases

The lock, and finally the next time it runs, thread 1 won ' t has to spin so much and would be able to acquire the lock.

Thus, any time a thread gets caught spinning in a situation like this, it wastes an entire time slice doing nothing but

Checking a value that's not going to change! The problem gets worse with N threads contending for a lock; N-1

Time slices May is wasted in a similar manner, simply spinning and waiting for a single thread to release the lock.

And thus, our next problem.

The crux:how to avoid spinning

How can we develop a lock this does not needlessly waste time spinning on the CPU?

Hardware support alone cannot solve this problem. We'll need OS support too! Let's now figure out just how

That's might work.

Os-tep:fetch-and-add