John McCall @rjmccall@hachyderm.io
Public

I'm pleased to announce that SE-0512: "Document that Mutex.withLockIfAvailable(_:) cannot spuriously fail" is now in review!

forums.swift.org/t/se-0512-doc

SE-0512: Document that Mutex.withLockIfAvailable(_:) cannot spuriously fail

Hello, Swift community. The review of SE-0512: Document that Mutex.withLockIfAvailable(_:) cannot spuriously fail begins now and runs through March 2nd, 2026. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to me as the review manager via either email or forum DM. When messaging me directly, please put "[SE-0512]" at the start of the subject line. Trying it out ...

forums.swift.org · Swift Forums

John McCall @rjmccall@hachyderm.io
Public

I spent a really unnecessary amount of time laying out the case for why I specifically think C and C++ were wrong-headed in standardizing a `tryLock` that *can* spuriously fail:

forums.swift.org/t/se-0512-doc

SE-0512: Document that Mutex.withLockIfAvailable(_:) cannot spuriously fail

Speaking for myself (i.e. not as the review manager), the proposal makes a reasonable case for this change, but I believe there's an even stronger argument for it. In particular, I think the C and C++ committees were wrong to standardize a weak tryLock operation. The only reason to specify a weak tryLock is to let it be implemented with a weak compare-exchange (CE). When both are directly implemented in hardware with similar ordering requirements, weak CEs are not generally faster than strong C...

forums.swift.org · Swift Forums

0
0
0

If you have a fediverse account, you can quote this note from your own instance. Search https://hachyderm.io/users/rjmccall/statuses/116089818277094499 on your instance and quote it. (Note that quoting is not supported in Mastodon.)