This PR adjusts the documentation for `Mutex.withLockIfAvailable()` to
clarify that it is not subject to spurious failures. The C11 and C++11
specs for their respective `tryLock()` APIs allow for spurious failures,
but our implementations and those of every other similar API I've found
don't use weak `cmpxchg`s and don't spuriously fail.
Implements
[SE-0512](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0512-withlockifavailable-cannot-spuriously-fail.md).
In #86276 strict memory safety becomes an error, necessitating adding
the following annotations and changes:
* in init(): check the return value of `pthread_mutex_init`; since this
isn't a failable initializer, `fatalError` if this fails, to avoid
silently leaving a zero-valued pointer,
* similarly check return values in `pthread_mutex_lock`,
`pthread_mutex_unlock`, and `pthread_mutex_destroy`,
* the message in `fatalError` should use `strerror_r`, which necessitates
`unsafe` markings since it initializes the array storage unsafely.
* marking the `value` as `@safe` since the underlying mutex type is an
`OpaquePointer` and is unsafe and all access to value occur through
a safe interface,
* thus, marking `_MutexHandle` `@safe`.
The FreeBSD Mutex implementation contained several un-annotated unsafe
pointer accesses resulting in build-failures after enabling strict
memory safety.
Fixes: #86289
In the comments it's stated that these errnos can't really occur for
the implementation, but unfortunately they have been seen in some
scenarios. To aide in debugging, it'd be nice to at least have the
errno in the error message.
On all platforms except Linux, calling `withLockIfAvailable()`
recursively just returns `nil`. However, our Linux implementation
chooses to abort the process instead. We don't need this
inconsistent/destructive behaviour and can just return `nil` as we do
elsewhere.
`pthread_mutex_trylock` return `0` on success.
```
NAME
pthread_mutex_trylock – attempt to lock a mutex without blocking
SYNOPSIS
#include <pthread.h>
int
pthread_mutex_trylock(pthread_mutex_t *mutex);
DESCRIPTION
The pthread_mutex_trylock() function locks mutex. If the mutex is already locked,
pthread_mutex_trylock() will not block waiting for the mutex, but will return an error
condition.
RETURN VALUES
If successful, pthread_mutex_trylock() will return zero, otherwise an error number will
be returned to indicate the error.
ERRORS
The pthread_mutex_trylock() function will fail if:
[EINVAL] The value specified by mutex is invalid.
[EBUSY] Mutex is already locked.
```
There has been some discussion as to whether this is the right approach,
centered around internal pointers in the underlying mutex structure.
After much thought, let's commit this for now. The argument:
* While it is true that OpenBSD has futex(2) and in fact is used in
the underlying implementations in Dispatch. I'm not confident right now
creating robust locking primitives by hand from futexes.
It would be ideal to just delegate all of this to Dispatch, but
Dispatch doesn't expose a ready-use API for mutexes. Cobbling one
together might be possible, but that would take some time and finesse.
* While recent versions of C and C++ have language support for mutexes,
they are implemented in many cases by libpthread anyway, so there
is nothing inherently gained right now by not using the pthread API
other than portability.
* While the concern for internal pointers for the pthread API is
important, the OpenBSD is mitigated by the fact that pthread_mutex_t is
pointer-valued on the platform. The concern that this might not always
be the case is mitigated by the fact that this commit does not attempt
to use the pthread implementation as a catch-all for all platforms.
* The alternative is to use MutexUnavailable, but given Foundation has
some dependencies on Mutex, this may cause problems elsewhere
throughout the port.
This commit adds required conditional compilation blocks to enable bulding on
FreeBSD (tested on x86_64 FreeBSD 14.1-RELEASE-p6). Also implements FreeBSD
synchronization shims using `_umtx_op(2)`
Annotate all of the `Unsafe*` types and `unsafe` functions in the standard
library (including concurrency, synchronization, etc.) as `@unsafe`. Add a
few tests to ensure that we detect uses of these types in clients that
have disabled unsafe code.
add_swift_target_library was missing pieces for passing sources and
flags to the static SDK build. As a result, the static SDK was missing
pieces (specifically Mutex).
Also adding the Musl import to the Linux Mutex implementation.
Use of atomics instructions requires the support of threads proposal and
it's not widely supported yet. So we should enable actual atomic
operations only when targeting wasm32-uknown-wasip1-threads.
This change fixes the following build error happening on Wasm:
```
error: referencing instance method '_wait(expected:)' on 'Atomic' requires the types '_MutexHandle.State' and 'UInt32' be equivalent
```
Sarunas
Jonathan Grynspan
3405691582
Evan Wilde
Danny Canter
Valeriy Van
Alejandro Alonso
Allan Shortlidge
michael-yuji
Max Desiatov
Michael Chiu
Doug Gregor
Evan Wilde
Alexander Cyon
Yuta Saito
Alex Lorenz