[HN Gopher] Fine-grained locking with two-bit mutexes
___________________________________________________________________
Fine-grained locking with two-bit mutexes
Author : ibobev
Score : 19 points
Date : 2022-12-06 16:41 UTC (1 days ago)
(HTM) web link (probablydance.com)
(TXT) w3m dump (probablydance.com)
| bawolff wrote:
| Sligtly off topic, but did anyone else do a double-take at the
| "make $1000 donation" form at the bottom?
| meta2023 wrote:
| Readable font-sizes don't come cheap!
| 95014_refugee wrote:
| Owner tracking and priority inheritance, anyone?
| bcrl wrote:
| We used simple bit spinlocks early in the multiprocessor
| scalability work done on the Linux kernel. While nearly "optimal"
| in terms of memory usage and simplicity, they tend to fall apart
| rather dramatically on systems with higher core counts. But
| they're a great step in the process of learning how to walk
| before running on bigger MP systems...
| the_optimist wrote:
| Can you elaborate and reference more on the "fall-apart" and
| approaches with more cores?
| arberx wrote:
| An efficient spinlock relies on a good kernel scheduler. I
| imagine that's the biggest hindrance to performance in a
| multicore system.
| gpderetta wrote:
| Note the mutex discussed in the article is not a spin lock, it
| actually sleeps on contention.
| zamalek wrote:
| One thing to be careful of is that mutexes are fair, spinlocks
| are not. It is possible for a worker to wait indefinitely behind
| workers acquiring the lock at a later time.
| connicpu wrote:
| Mutexes aren't necessarily fair, and there's some good reasons
| you may not want true fairness in your lock[1] (that said, most
| implementations try to be as fair as they can be without
| introducing too much overhead)
|
| [1]: http://joeduffyblog.com/2006/12/14/anticonvoy-locks-in-
| windo...
___________________________________________________________________
(page generated 2022-12-07 23:01 UTC)