Paul Eggert wrote: > Emacs has its own idea about locks emacs/src/systhread.c has a similar approach as gnulib regarding locking: it defines an implementation for Unix, and implementation for native Windows, and an implementation for no multithreading at all.
I think that locking is ultimately unavoidable, because modules need to be able to cache intermediate results, and I don't believe that lock-free data structures are competitive with the locking approach. (*) In particular, the nstrftime module will definitely need to get locking (unless we reduce its timezone_t argument to a mere 'bool'). What could be done to solve this conflict, either on the Emacs side or on the Gnulib side? Any ideas, Paul? Bruno (*) I mean, competitive w.r.t. * Maintainability: Are there good textbooks which describe how to implement a lock-free linked list, a lock-free vector, and a lock-free hash map? If not, it's a problem. * Reliability: I understand that lock-free code uses compare-and- exchange instructions in many places. If the code uses a plain store where it should use a compare-and-exchange, there is a bug. What techniques exist for finding and eliminating these bugs? * Efficiency: With the futex-based locks that we have nowadays, taking a lock up-front is likely to be cheaper than doing a compare-and-exchange 10 times, isn't it? If I am wrong on all three accounts, feel free to correct me, and submit lock-free data structure implementations.