Protecting the ECP hardware acceleratior with mutexes is inconsistent with the
philosophy of the library. Pre-existing hardware accelerator interfaces
leave concurrency support to the underlying platform.
Fixes#863
The primary use case behind providing an abstraction layer to enable
alternative Elliptic Curve Point arithmetic implementation, is making
use of cryptographic acceleration hardware if it is present.
To provide thread safety for the hardware accelerator we need a mutex
to guard it.
Due to inconsistent freeing strategy in pkparse.c the sample mutex
implementation in threading.c could lead to undefined behaviour by
destroying the same mutex several times.
This fix prevents mutexes from being destroyed several times in the
sample threading implementation.
* gmtime_r is not standard so -std=c99 warns about it
* Anyway we need global mutexes in the threading layer, so better depend only
on that, rather that global mutexes + some _r functions
