"Operating System Concepts" notes the critical section problem - TSL & mutex lock

mutex lock is built on a piece of hardware on the special instructions given by the operating system solutions.

Senior actually call test_and_set and compare_and_swap and other instructions. Of course, here the test and set and compare and swap instruction is not implemented in a specific platform, just abstract definitions of the two types of instruction.

If you are not familiar with the test and set, then the test and set instruction is defined as such

bool tas(bool *target){
  bool rv = *target;
  *target = true;
  return rv
}

Of course, this is only the definition, the entire command is atomic as the command of a.

Use test and set command to achieve mutual exclusion look like this:

do{
  while(tas(&lock))
      ;
  /*critical section*/
  lock = false;
  /*remainder section*/
}while(true);

lock the outset is initialized to false, then the implementation of the first sentence while (tas (& lock)) when
two things happen, the first sentence is a result in itself is false, thus allowing the thread down into the next execution critical section, the second sentence is assigned to the lock true.

And when lock takes true value, if the second thread to perform the first sentence while (tas (& lock)), it will be an infinite loop busy waiting. You can not enter the critical section until the first thread lock is set to false. At that time the first thread will have left the critical region, and reached mutually exclusive effect.

compare_and_swap instructions are defined as follows:

int cas(int *val, int exp, int new_val){
  int tmp = *val;
  if(*val = exp)
    *val = new_val;
  return tmp;
}

Exclusive use cas command:

lock = 0;
do{
  while(cas(&lock,0,1) != 0 )
    ;
  lock = 0;
}while(true);

Commands cas analysis is not difficult.

Two or more operating systems provide hardware solutions. But it is a pity that the compilation of the user program generally do not develop. So similar to pthread, windows will provide solutions on software.

The most direct idea is mutex lock: Before entering the critical region should get a lock, do not lock the other threads can not enter the critical section, leaving the critical region should release the lock out, so that other threads get lock.

--- two of the lock operation is obtained, release is defined as follows:

acquire(){
  while(!available)
    ;
  available = false;
}

release(){
  available = true;
}

Note that, acquire and release of all atomic.

See the definition of acquire is not the time felt a wave of déjà vu? Recall tas, the first sentence of two actions when performed while, we will lock become true from false, we
tas instruction returns false, so that while the idle loop is not executed.

Here, available by default true, so that while the idle loop does not execute, then we will be available from the true becomes false.

As the lock (available!), We know that tas fixed lock = true, which is available = false;
here with tas realize it acquire:

/*初始化lock = false*/
while(tas(&lock)) 
  ;

tas (& lock) returns false, enter the critical region, while lock = true hinder other processes enter the critical region.

But because tas command can only be achieved lock = true is available = false, so we can not use it to achieve release, this time we can use the command cas

The release achieved as follows:

cas(&lock, false, true);

When the lock = false, we will change him into a true.

So we now have the TSL and mutex lock.

Reproduced in: https: //www.jianshu.com/p/4d8e56461f7b

"Operating System Concepts" notes the critical section problem - TSL & mutex lock

Guess you like