Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5886)

Use a read lock when reading using pthreads.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4517)

Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4414)

in an atomic fashion.
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/4414)

Only for Unix platforms
Reviewed-by: NRichard Levitte <levitte@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/3754)

This reverts commit 349d1cfd.

The proposed fix is incorrect. It marks the "run_once" code as having
finished before it has. The intended semantics of run_once is that no
threads should proceed until the code has run exactly once. With this
change the "second" thread will think the run_once code has already been
run and will continue, even though it is still in progress. This could
result in a crash or other incorrect behaviour.
Reviewed-by: NTim Hudson <tjh@openssl.org>

Fixed deadlock in CRYPTO_THREAD_run_once() if call to init() is causing
a recursive call to CRYPTO_THREAD_run_once() again that is causing a hot
deadloop inside do { } while (result == ONCE_ININIT); section.

CLA: trivial
Reviewed-by: NRichard Levitte <levitte@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1913)

If application uses any of Windows-specific interfaces, make it
application developer's respondibility to include <windows.h>.
Rationale is that <windows.h> is quite "toxic" and is sensitive
to inclusion order (most notably in relation to <winsock2.h>).
It's only natural to give complete control to the application developer.
Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>

The function InitOnceExceuteOnce is the best way to support the
implementation of CRYPTO_THREAD_run_once() on Windows. Unfortunately
WinXP doesn't have it. To get around that we had two different
implementations: one for WinXP and one for later versions. Which one was
used was based on the value of _WIN32_WINNT.

This approach was starting to cause problems though because other parts of
OpenSSL assume _WIN32_WINNT is going to be 0x0501 and crashes were
occurring dependant on include file ordering. In addition a conditional
based on _WIN32_WINNT had made its way into a public header file through
commit 5c4328f0. This is problematic because the value of this macro can
vary between OpenSSL build time and application build time.

The simplest solution to this mess is just to always use the WinXP version
of CRYPTO_THREAD_run_once(). Its perhaps slightly sub-optimal but probably
not noticably.

GitHub Issue #1086
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Reviewed-by: NRichard Levitte <levitte@openssl.org>

Document thread-safe lock creation
Reviewed-by: NRichard Levitte <levitte@openssl.org>

InitOnceExecuteOnce returns nonzero on success:
MSDN: "If the function succeeds, the return value is nonzero."

So return 1 if it is nonzero, 0 others.
Reviewed-by: NMatt Caswell <matt@openssl.org>
Reviewed-by: NRich Salz <rsalz@openssl.org>

return type should be int and not void
Signed-off-by: NRich Salz <rsalz@akamai.com>
Reviewed-by: NRichard Levitte <levitte@openssl.org>

Signed-off-by: NRich Salz <rsalz@akamai.com>
Reviewed-by: NMatt Caswell <matt@openssl.org>

Reviewed-by: NRich Salz <rsalz@openssl.org>
Reviewed-by: NMatt Caswell <matt@openssl.org>