https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119796
--- Comment #5 from AlphaOmegaProgrammer <alpha.and.omega.programmer at gmail dot com> --- > Please see https://gcc.gnu.org/contribute.html for how to contribute, which > includes sending a real patch My apologies, this is my first time trying to contribute. I'll do this. > This can only occur for atomic operations on huge objects though, right? With the current implementation, it can theoretically happen on objects roughly of size 4096 bytes / # of competing threads. > it seems that the deadlock could be avoided by always locking the mutexes > in the same order, i.e. start with the lowest address in the array, rather > than starting with higher addresses and then wrapping around to a lower > address. I thought about this, but the conclusion that I came to is that there are only 2 possible approaches: * You can do what the current implementation does and index with the low bits of the memory address. * You can try to divide the entire memory space into buckets by indexing with the high bits of the memory address. The first approach obviously is prone to deadlocks using the method I've demonstrated. The second approach would allow for indexing sequentially and avoid wrapping the index around, but now if your object is smaller than the total memory space / total # of mutexes, then one thread effectively blocks every other thread trying to touch memory in that entire region of memory, which effectively makes it a global lock anyway. > That's not true, std::lock() uses an algorithm that works for that case. > See https://howardhinnant.github.io/dining_philosophers.html for details on > the problem. I will look into these before submitting a proper patch. Thanks, AOP
