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.
