#805 closed enhancement (fixed)
Fast read/write locker
| Reported by: | axeld | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | R1/beta2 |
| Component: | Network & Internet/Stack | Version: | |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Platform: | All |
Description
The locking mechanism is currently too strict, and prevents concurrency where there is no need to. We need a multiple reader/single writer locking mechanism that is based on the benaphore mechanism. A read lock should be upgradeable to a write lock.
Change History (6)
comment:1 by , 17 years ago
| Milestone: | R1 Network Stack → R1 |
|---|---|
| Platform: | → All |
comment:2 by , 16 years ago
| Component: | System/Kernel → Network & Internet/Stack |
|---|---|
| Priority: | normal → low |
comment:3 by , 16 years ago
comment:4 by , 16 years ago
I have no idea anymore :-) I guess we should put this ticket aside until we have real concurrency speed problems to solve.
comment:5 by , 6 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
rw_lock was changed to be almost entirely atomics (with a "25% kernel time reduction on Haiku builds") in 2009, so I'd say this is resolved. We can revisit performance issues later if needed.
comment:6 by , 5 years ago
| Milestone: | R1 → R1/beta2 |
|---|
Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone
Note:
See TracTickets
for help on using tickets.
What properties should the upgrade to write lock function have? I suppose you've something different in mind than read unlock + write lock.