This adds a wait bit to refcount with an atomic sleep. Consumers that use this facility need to be aware that specific count values can not be examined directly.
When a counter is saturated this will block forever.
Details
Details
Diff Detail
Diff Detail
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 25875 Build 24444: arc lint + arc unit
Event Timeline
Comment Actions
I'm not really crazy about this to be honest. refcount_release() gets inlined hundreds if not thousands of times into various functions. Now all of those callers are polluted with extra dead branch to call wakeup(). The fences in refcount_release() also don't make sense when refcount_wait() is used since a refcount of 0 doesn't mean that the protected object is unreachable, the way you'd normally expect a refcount to work. I would argue that this use-case would be better served by a new KPI or something open-coded.
That said, I don't see any technical issues aside from the nits I pointed out.
| sys/sys/refcount.h | ||
|---|---|---|
| 45 | The use of bit 31 meant that we could detect saturation with a single js instruction after the acquire, but that's no longer true with this change. | |
| 88 | Extra newline. | |
| 91 | We should assert some bound on n, probably 2^30? | |
Comment Actions
Address some of Markj's feedback. Move the last ref drop into a dedicated function to lessen text bloat.
| sys/kern/kern_synch.c | ||
|---|---|---|
| 363 | Never mind, that only applies to fcmpset. | |
| sys/kern/kern_synch.c | ||
|---|---|---|
| 370 | There is no _rel at the beginning of the function. You need to point to the refcount_releasen(). | |