Synchronization Lock

In contrast to a mutex lock, a synchronization lock is the weakest form of lock and used solely for synchronization.

A synchronization lock is often called a condition lock, with wait/signal(notify) for acquire/release.

Synchronization lock

Is used solely to block tasks waiting for synchronization.

While a synchronization lock has internal state to manage tasks blocked waiting for an event, it does not retain state about the status of the event it may be associated with. That is, a synchronization lock does not know if the event has or has not occurred; its sole purpose is to block and unblock tasks from a list, usually in FIFO order.

Two kinds:

• external locking
  • synchronization lock uses an external mutex lock to protect its state
• internal locking
  • synchronization lock uses an internal mutex lock to protect its state

DIdn't understand this ^

An alternate implementation binds a specific mutex lock to a synchronization lock, via the constructor, for the lifetime of the synchronization lock.

• mutexlock is fixed $\to$ reduces chance for errors, it is no longer passed as a parameter to member acquire.

The following usage pattern illustrates how an internal synchronization-lock is used:

• Blocking occurs holding external mutual-exclusion lock!
• $\Rightarrow$ release lock before blocking by modifying synchronization-lock acquire.

Same:

• As before, preemption results in race between blocking and unblocking tasks.
  • race problem of releasing the mutual-exclusion lock and blocking lock on synchronization lock.
• To prevent the race, other form of acquire is used to release lock using the first usage pattern

Has the race been prevented?

Yes, because of the magic in yieldNoSchedule, which blocks and releases the mutex lock atomically

• Use barging avoidance:

or prevention:

• internal locking

  • Why does acquire still take an external lock?
  • Why is the race releasing the external mutex-lock not a problem?

• Has the busy wait been removed from the blocking lock?