crypto: add mutexes. Prior to this, BoringSSL was using OpenSSL's technique of having users register a callback for locking operation. This change adds native mutex support. Since mutexes often need to be in objects that are exposed via public headers, the non-static mutexes are defined in thread.h. However, on Windows we don't want to #include windows.h for CRITICAL_SECTION and, on Linux, pthread.h doesn't define pthread_rwlock_t unless the feature flags are set correctly—something that we can't control in general for public header files. Thus, on both platforms, the mutex is defined as a uint8_t[] of equal or greater size and we depend on static asserts to ensure that everything works out ok. Change-Id: Iafec17ae7e3422325e587878a5384107ec6647ab Reviewed-on: https://boringssl-review.googlesource.com/4321 Reviewed-by: Adam Langley <agl@google.com>
diff --git a/include/openssl/thread.h b/include/openssl/thread.h index 1f8f524..f9b9980 100644 --- a/include/openssl/thread.h +++ b/include/openssl/thread.h
@@ -64,6 +64,27 @@ #endif +#if defined(OPENSSL_WINDOWS) +/* CRYPTO_MUTEX can appear in public header files so we really don't want to + * pull in windows.h. It's statically asserted that this structure is large + * enough to contain a Windows CRITICAL_SECTION by thread_win.c. */ +typedef union crypto_mutex_st { + double alignment; + uint8_t padding[4*sizeof(void*) + 2*sizeof(int)]; +} CRYPTO_MUTEX; +#else +/* It is reasonable to include pthread.h on non-Windows systems, however the + * |pthread_rwlock_t| that we need is hidden under feature flags, and we can't + * ensure that we'll be able to get it. It's statically asserted that this + * structure is large enough to contain a |pthread_rwlock_t| by + * thread_pthread.c. */ +typedef union crypto_mutex_st { + double alignment; + uint8_t padding[3*sizeof(int) + 5*sizeof(unsigned) + 16 + 8]; +} CRYPTO_MUTEX; +#endif + + /* Functions to support multithreading. * * OpenSSL can safely be used in multi-threaded applications provided that at