19 lines
No EOL
1.4 KiB
Markdown
19 lines
No EOL
1.4 KiB
Markdown
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
|
|
1. **Obstruction freedom:** every time an operation is run in isolation (no overlap with any other operation on the same object), it terminates
|
|
2. **Non-blocking:** whenever an operation is invoked on an object, eventually one operation on that object terminates
|
|
- reminds deadlock-freedom in MUTEX-based concurrency
|
|
3. **Wait freedom:** whenever an operation is invoked on an object, it eventually terminates
|
|
- reminds starvation-freedom in MUTEX-based concurrency
|
|
4. **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). |