# What does "Use async-safe scoped locking instead" even mean?

**URL:** <https://forums.swift.org/t/what-does-use-async-safe-scoped-locking-instead-even-mean/61029>\
**Category:** Using Swift\
**Created:** [October 26, 2022, 9:38am UTC](https://forums.swift.org/t/what-does-use-async-safe-scoped-locking-instead-even-mean/61029 "2022-10-26T09:38:12Z")\
**Posts on this page:** 1\
**Showing post:** 12

<div class="post-metadata">

**Author:** ![gwendal.roue](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/gwendal.roue/32/13992_2.png) [@gwendal.roue](https://forums.swift.org/u/gwendal.roue)\
**Post date:** [October 26, 2022, 10:39am UTC](https://forums.swift.org/t/what-does-use-async-safe-scoped-locking-instead-even-mean/61029/12 "2022-10-26T10:39:04Z")

</div>

> `AsyncSemaphore` still uses a regular lock inside

I still don't know if this is due to the [bad interaction between Xcode 14 and macOS before 13](https://forums.swift.org/t/concurrency-is-broken-in-xcode-14-for-macos/60294), or if this is strictly necessary. The people responsible for Swift concurrency won't discuss the proper way to implement a counting semaphore in a way that 1. fits their view of Swift concurrency, 2. back-deploys, 3. deals with Xcode 14 and macOS in the less painful way possible. ¯\_(ツ)\_/¯

Did I mention that testing such code is hum hum tricky, since iOS simulators have a limited thread pool, and macOS faces the difficulties linked above?

When locks can be removed, `AsyncSemaphore` will stop using them. So far, this code is reliable to my knowledge. It answers the OP's question, and beyond (cancellation).

---

_[View the full topic](https://forums.swift.org/t/what-does-use-async-safe-scoped-locking-instead-even-mean/61029)._