1.4 KiB
1.4 KiB
Critical sections (locks) have drawbacks:
- if not put at the right level of granularity, they unnecessarily reduce concurrency
- delays of one process may affect the whole system
MUTEX-freedom: the only atomicity is the one provided by the primitives themselves (no wrapping of code into CSs) the liveness properties used so far cannot be used anymore, since they rely on CSs. (example: if we have only atomic R/W registers, these are the only atomic things that we have. But we may also have atomic primitives like test&set, compare&swap ecc.).
Liveness properties
We have four new liveness properties
- Obstruction freedom: every time an operation is run in isolation (no overlap with any other operation on the same object), it terminates
- Non-blocking: whenever an operation is invoked on an object, eventually one operation on that object terminates
- reminds deadlock-freedom in MUTEX-based concurrency
- Wait freedom: whenever an operation is invoked on an object, it eventually terminates
- reminds starvation-freedom in MUTEX-based concurrency
- Bounded wait freedom: W.F. plus a bound on the number of steps needed to terminate
- reminds bounded bypass in MUTEX-based concurrency
REMARK: these notions naturally cope with (crash) failures. Fail stop is another way of terminating, there is no way of distinguishing a failure from an arbitrary long sleep (because of asynchrony).