Re: gnulib: cond & spinlocks

[Bruno Haible]

Vladimir, Sam,

> >> I plan to create the thread2 branch after I switch to gnulib
> >> threadlib/lock/cond to get solaris and win32 "for free".

As I wrote to Sam on 2008-08-17 in private mail: For clisp, I would attempt
to stay with the POSIX threads API, rather than using gnulib's wrapper
modules. Why?
  - gnulib's modules are targeted at the average application programmer,
    whereas clisp is more at the system programming level.
  - The POSIX threads API is better documented than gnulib's wrapper modules.
  - For the platforms that are interesting for clisp (Linux, *BSD, MacOS X,
    Solaris, Windows), POSIX threads are either well supported or emulated
    using the pthreads-win32 package.
  - You want additionally spinlocks, which POSIX has
    (<http://www.opengroup.org/susv3/functions/pthread_spin_init.html>) but
    gnulib does not yet have.

The only advantages of gnulib's modules in this case are
  - A more systematic naming convention of the functions,
  - Portability to older OSes, like Solaris 7, Tru64, and similar.

Like with the execute/pipe modules and posix_spawn, also here with the threads
I think the way to go is to separate the gnulib functionality into
  1. an emulation the POSIX API,
  2. a convenience API layer on top of the POSIX API.

> would it be possible to make gnulib cond allocate on stack?

You mean, the gl_cond_t variable should be allocated on the stack? It is
already possible. But note that the extent of such a variable must encompass
the lifetime of the threads that use it; that's why it is usually allocated
with indefinite extent.

> would it be possible to use fast clisp spinlocks in gnulib lock?

That code is CPU dependent and relies on GCC's inline asms. It is certainly
better to use pthread_spin_* where available (and emulate them where not
available - but that might be hard if not assuming GCC).

Regarding clisp's xthread.d: The first thing I would do now is to ditch the
conditional code for POSIXOLD_THREADS, SOLARIS_THREADS, C_THREADS. You don't
need these APIs any more. And with pthreads-win32 you don't need WIN32_THREADS
either.

> > The xmutex_t should be recursive (for consistency - critical section  
> > on Win32 are recursive - and gnulib uses them as well).

Both POSIX and gnulib offer normal and recursive locks. You just choose
which one you need.

> > The cond implementation in gnulib uses malloc() while the current  
> > clisp implementation uses the stack.

There is a comment in gnulib/lib/glthread/cond.c that explains why here
malloc() is better than stack allocation.

> > I just looked on the gnulib and do not see "realy fast" spinlocks  
> > (may be I am wrong - have not looked too hard). In the current clisp  
> > spinlocks are inlined assembly instructions. Every heap allocation is  
> > guarded with a spinlock - so any overhead may cause significant  
> > decrease in performance.

Do you want to help implementing fast pthread_spin_* replacement functions
in gnulib? This would be a benefit for both clisp and gnulib:
  - clisp could use the pthread_spin_* functions from the OS when they are
    good enough or when the CPU is exotic,
  - gnulib would have fast pthread_spin_* functions.

Bruno