Proposal for memory ordering in Swift?

Are there any current evolution proposals for something in Swift that will enforce non-blocking memory ordering (that will emit code for atomic operations and/or un-reordered memory barriers) ? Especially for structs that contain a "valid" flag. If not, what might suitable Swift syntax or types or pragmas (etc.) for such look like?


This seems to be required to ensure safe real-time inter-thread communcation on any current ARM architecture multi-processors. Non-blocking inter-thread communication seems to be required for audio threads, as audio callbacks are recommended (currently, in Apple's Audio Unit documentation) never to do anything that could take a lock or block in any other manner.

Replies

Visit swift.org and search archives of swift-evolution mailing list. The mailing list is getting too huge that very few can trace all the discussions in detail.


You can write your own proposals with participating in the mailing list. With writing directly to the mailing list, you have far better chance that your proposals get found by the Swift Core Team.

In Swift 3 and on iOS 10 and macOS Sierra you can utilize a subset of the <stdatomic.h> C library.


This is the synthesized header:


/* 7.17.1 Introduction */
public var ATOMIC_BOOL_LOCK_FREE: Int32 { get }
public var ATOMIC_CHAR_LOCK_FREE: Int32 { get }
public var ATOMIC_CHAR16_T_LOCK_FREE: Int32 { get }
public var ATOMIC_CHAR32_T_LOCK_FREE: Int32 { get }
public var ATOMIC_WCHAR_T_LOCK_FREE: Int32 { get }
/* 7.17.2 Initialization */
/* 7.17.3 Order and consistency */
public struct memory_order : RawRepresentable, Equatable {
    public init(_ rawValue: UInt32)
    public init(rawValue: UInt32)
    public var rawValue: UInt32
}
public var memory_order_relaxed: memory_order { get }
public var memory_order_consume: memory_order { get }
public var memory_order_acquire: memory_order { get }
public var memory_order_release: memory_order { get }
public var memory_order_acq_rel: memory_order { get }
public var memory_order_seq_cst: memory_order { get }
/* 7.17.4 Fences */
/* These should be provided by the libc implementation. */
public func atomic_thread_fence(_: memory_order)
public func atomic_signal_fence(_: memory_order)
/* 7.17.5 Lock-free property */
/* 7.17.6 Atomic integer types */
/* 7.17.7 Operations on atomic types */
/* 7.17.8 Atomic flag type and operations */
public struct atomic_flag {
    public init()
}
/* These should be provided by the libc implementation. */
public func atomic_flag_test_and_set(_: UnsafeMutablePointer<atomic_flag>!) -> Bool
public func atomic_flag_test_and_set_explicit(_: UnsafeMutablePointer<atomic_flag>!, _: memory_order) -> Bool
public func atomic_flag_clear(_: UnsafeMutablePointer<atomic_flag>!)
public func atomic_flag_clear_explicit(_: UnsafeMutablePointer<atomic_flag>!, _: memory_order)

Alas. According to a reply from Apple Staff in: https://forums.developer.apple.com/thread/49334 it appears that even C library atomics are currently not guaranteed to stay atomic when used in Swift. It appears that there may be no way, currently, to tell the Swift compiler not to break up C atomics and/or reorder sequential barriers such that variables can get reordered into an illegal state, as seen by other processors/threads.


This seems to make using Audio Unit callbacks from Swift either illegal or dangerous.