Opened 13 years ago

Closed 8 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:


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 by Jakub Jermář, 13 years ago

I'd prefer to have explicit interfaces for this so that the rwlock does not make a false impression of being recursive:

  • fibril_rwlock_upgrade()
  • fibril_rwlock_downgrade()

fibril_rwlock_downgrade()'s usefulness is debatable as the writer can read the shared data too.

comment:2 by Jakub Jermář, 13 years ago

Owner: set to Jakub Jermář
Status: newassigned

comment:3 by Jakub Jermář, 13 years ago


comment:4 by Jakub Jermář, 13 years ago

Type: proposalenhancement

comment:5 by Jakub Jermář, 12 years ago


comment:6 by Jiří Zárevúcky, 11 years ago

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.

Last edited 11 years ago by Jiří Zárevúcky (previous) (diff)

comment:7 by Jakub Jermář, 9 years ago


comment:8 by Jakub Jermář, 8 years ago

Resolution: wontfix
Status: assignedclosed
Note: See TracTickets for help on using tickets.