Subject: Re: Thread safety issues

Re: Thread safety issues

From: Michel Valin <>
Date: Tue, 31 Aug 2010 07:49:49 -0400

Simon Josefsson wrote:
> 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.

This one can be alleviated by having the library issue a warning message
at first initialization (lib_sh2_init) reminding the user that the
thread-safe hook is not set.

> - 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,
> 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

Michel Valin
Responsable, Soutien CHP | Head, HPC support
CHP & Opérations des TI nationales
HPC & National IT Operations
Direction du dirigeant principal de l'information
Chief Information Officer Branch
Environnement Canada | Environment Canada
2121, N. Trans canada, Dorval, QC, CANADA  H9P 1J3
Téléphone   | Telephone 514-421-4753
Télécopieur | Facsimile 514-421-4703
Gouvernement du Canada | Government of Canada
Entre deux mots, il faut choisir le moindre.
Always choose the shortest of two words.
Paul Valéry
Received on 2010-08-31