What if you would like to implement a busy-wait semantic; that is, test for the availability of the (mutex) lock and, if available (meaning it's currently unlocked), acquire/lock it and continue with the critical section code path? If this is not available (it's currently in the locked state), do not wait for the lock; instead, perform some other work and retry. In effect, this is a non-blocking mutex lock variant and is called the trylock; the following flowchart shows how it works:
Figure 12.8 – The "busy wait" semantic, a non-blocking trylock operation
The API for this trylock variant of the mutex lock is as follows:
int mutex_trylock(struct mutex *lock);
This API's return value signifies what transpired at runtime:
- A return value of 1 indicates that the lock has been successfully acquired.
- A return value of 0 indicates that the lock is currently contended (locked).
Though it might sound...