thread-safety when used by a library

Werner Koch wk at
Tue Dec 18 10:41:30 CET 2012

On Thu, 13 Dec 2012 16:29, nmav at said:

> to semaphore. Since you don't care about locks across processes having
> semaphores would not provide any advantage, and I'd expect also

The advantage is that semaphores are async-signal-safe, have no owner,
and have proper fork semantics.

> mutexes to be more efficient in threads than semaphores. We use

Marcus did some tests before he used a semaphore in nPth and cam to the
conclusion that there is no performance penalty compared to a mutex.

> 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

You are still trapped by all the Posix mutex peculiarities.  In
particular, an application may not know which library it uses and thus
it would be better for the library to be free of all possible problems.

I will do some more tests, though.



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

More information about the Gcrypt-devel mailing list