Opened 10 years ago
Closed 5 years ago
#271 closed enhancement (wontfix)
Fibril rwlocks read/write lock switch
Reported by: | Radim Vansa | Owned by: | Jakub Jermář |
---|---|---|---|
Priority: | minor | Milestone: | 0.7.0 |
Component: | helenos/lib/c | Version: | mainline |
Keywords: | fibril synchronization | Cc: | |
Blocker for: | Depends on: | ||
See also: |
Description
When a fibril rwlock is already locked for writing and the function fibril_rwlock_read_lock() is called, the rwlock should atomically go to read-only lock state (instead of deadlock error). The similar should happen when the lock is acquired for reading and we want to lock it for writing (just in this case it can temporarily block, of course).
Change History (8)
comment:1 Changed 10 years ago by
comment:2 Changed 10 years ago by
Owner: | set to Jakub Jermář |
---|---|
Status: | new → assigned |
comment:3 Changed 10 years ago by
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:4 Changed 10 years ago by
Type: | proposal → enhancement |
---|
comment:5 Changed 9 years ago by
Milestone: | 0.5.0 → 0.5.1 |
---|
comment:6 Changed 8 years ago by
There is one thing that needs to be understood about the proposed upgrade operation. If more than one reader request upgrade, then either all deadlock or all but one lose the lock.
When the fibril loses the lock in the middle of upgrade, how should it behave? Should it just fail and return, or should it behave as an unlock-writelock sequence? Either way needs code to handle the fail case, which makes this operation a pure performance optimization; one that can lead to really nasty bugs if misunderstood by someone.
comment:7 Changed 7 years ago by
Milestone: | 0.5.1 → 0.5.2 |
---|
comment:8 Changed 5 years ago by
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
I'd prefer to have explicit interfaces for this so that the rwlock does not make a false impression of being recursive:
fibril_rwlock_downgrade()'s usefulness is debatable as the writer can read the shared data too.