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
