thread-safety when used by a library
wk at gnupg.org
Tue Dec 18 10:41:30 CET 2012
On Thu, 13 Dec 2012 16:29, nmav at gnutls.org 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