bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Emacs locking vs. gnulib locking


From: Bruno Haible
Subject: Emacs locking vs. gnulib locking
Date: Sun, 18 Feb 2024 03:53:16 +0100

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]