thread-safety when used by a library

[Nikos Mavrogiannopoulos]

On Thu, Dec 13, 2012 at 11:35 AM, Werner Koch <wk at gnupg.org> wrote:

>> Could you share a general plan how would you like to deal with that issue?
> This has already been fixed in Libgcrypt master.  There are still the
> usual problems with libraries and pthreads left (e.g. the not 100%
> solvable problems with fork and pthread).
> One think I am still thinking about is to use semaphores instead of
> mutex.  They don't have the pthread problems and are sufficient for
> Libgcrypt purposes.  The only drawback I can see is the requirement to
> link against librt.  nPth uses semaphores so at least for GnuPG 2.1 it
> is a link dependency anyway.

I think that the mutex is particularly suited for that usage, compared
to semaphore. Since you don't care about locks across processes having
semaphores would not provide any advantage, and I'd expect also
mutexes to be more efficient in threads than semaphores. We use
mutexes in gnutls for locking (and critical sections in windows) with
no issues so far (applications with special needs can always override
the provided locks with their own, but I'm not aware of any doing
that).

About the the issues with fork and pthreads, I think they cannot be
solved by a library and users who mix them should figure a proper
initialization sequence anyway. Applications that do that maybe should
be allowed to register their own locks they can control (I don't think
there's is a great deal of such applications though).

regards,
Nikos