Subject: Re: Thread safety issues

Re: Thread safety issues

From: Simon Josefsson <simon_at_josefsson.org>
Date: Mon, 30 Aug 2010 17:28:10 +0200

I've been pondering on the thread library problem for a couple of
libraries already, and the problem is Hard. The dominant solutions are:

0) Don't do anything and require callers to setup threading.

  Pros:
  - The library is simpler and doesn't link to a thread library.

  Cons:
  - Layer violation, callers needs to be aware of the crypto library
    used by libssh2 and setup mutex appropriately.

1) Provide an APIs and let the caller set mutex hooks.

   Pros:
   - The library does not have to link a thread library.
   - No layering violation.

   Cons:
   - It is easy to forget to make this call when you are writing
     a multi-threaded program, which can lead to subtle errors.
   - It is complicated to initialize the library correctly if you
     have one big application that links to two separate libraries that
     both in turn link to libssh2.

2) Hard-code the thread implementation to support during build time.

   Pros:
   - Easier to use, as things happens automatically.

   Cons:
   - Even non-threaded applications now link to libpthread and call
     thread-related functions.
   - May result in multiple libraries, one for each thread
     implementation. E.g., libssh2_pthread, libssh2_gnupth,
     libssh2_nptl, etc.

There are some other alternatives, but I don't recall them now.

I have yet to use alternative 2 successfully for a low-level shared
library. Pthreads appears to be the "winning" thread implementation on
GNU systems, so maybe it could be considered here? On my system,
libldap.so is linking to pthreads so the approach has been tested.
(However, I think there are some tricky bugs for libldap caused by this
decision.)

Personally, my experience is that threaded programs are impossible to
maintain and keep reliable in the long run (10+ years) due to the higher
complexity. This is why I prefer approach 0 or 1, which puts the effort
on the shoulders on those that uses threading. The downside is that it
is not a responsible decision because the reality is that some things
are threaded and one has to deal with it.

For a library like libssh2, the part that really needs mutexes today is
the RNG. Crypto libraries needs mutexes when hashing its global entropy
pool. In GnuTLS we are experimenting with using GNU Nettle (which is a
completely thread safe crypto library) and some internal randomness
functionality. I'm hoping this will work out, but it is too early to
tell.

/Simon
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-08-30