# Using semaphores in actor code

**URL:** <https://forums.swift.org/t/using-semaphores-in-actor-code/58301>\
**Category:** Using Swift\
**Tags:** concurrency\
**Created:** [June 20, 2022, 6:48am UTC](https://forums.swift.org/t/using-semaphores-in-actor-code/58301 "2022-06-20T06:48:19Z")\
**Posts on this page:** 1\
**Showing post:** 14

<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:** [February 22, 2024, 1:23pm UTC](https://forums.swift.org/t/using-semaphores-in-actor-code/58301/14 "2024-02-22T13:23:51Z")

</div>

> [@tera](#):
>
> Isn't the same true about [locks](https://forums.swift.org/t/pitch-synchronous-mutual-exclusion-lock)?

Yes, because a lock acquired by a low-priority job will block a high-priority job. Now, locks usually protect a very short piece of synchronous code. This makes locks a less nasty beast than async semaphores, even if you can write programs that use locks in a pathological way. See also this answer about the relationship between locks and Swift concurrency: [[Pitch] Synchronous Mutual Exclusion Lock - #15 by Alejandro](https://forums.swift.org/t/pitch-synchronous-mutual-exclusion-lock/69889/15)

Finally, developers still need to synchronize threads. The linked pitch states:

> The main issue is that there isn't a single standardized implementation for this synchronization primitive resulting in everyone needing to roll their own.

---

_[View the full topic](https://forums.swift.org/t/using-semaphores-in-actor-code/58301)._