Recursive (Re-Entrant) Locks (2013)

Re:Recursive (Re-Entrant) Locks (2013) by magicalhippo on Saturday February 18, 2023 @06:47AM (#34846152)

Indeed. I worked on a non-trivial project (~300kLOC C++) which was heavily multi-threaded and relied on recursive locks. It had lots of issues with not taking locks at the right time and so on.

I took some time to refactor it all to not use recursive locks, instead having a clean boundary between internal (non-locking) methods and external methods which did the locking and called the internal ones.

Not only did our locking issues go away immediately, it lead to a much simpler developer experience since there was never any question if this new function needed to lock or not etc.

I've not written that heavy multi-threaded code since, but my takeaway from the experience was that requiring recursive locks was a sign of poor design.

[ Parent | on HN ]

Re:Recursive (Re-Entrant) Locks (2013) by magicalhippo on Saturday February 18, 2023 @09:15AM (#34847079)

I forgot to mention performance increased a fair bit as well, since a lot less locking was done.

Instead of one "public" function call resulting in locking the same lock recursively 4-5 times as the "public" function called other functions and so on, a single locking operation was done at the boundary.

[ Parent | on HN ]