# \[Pitch\] Synchronous Mutual Exclusion Lock

**URL:** <https://forums.swift.org/t/pitch-synchronous-mutual-exclusion-lock/69889>\
**Category:** Pitches\
**Tags:** concurrency, mutex\
**Created:** [February 6, 2024, 11:51pm UTC](https://forums.swift.org/t/pitch-synchronous-mutual-exclusion-lock/69889 "2024-02-06T23:51:59Z")\
**Posts on this page:** 1\
**Showing post:** 43

<div class="post-metadata">

**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\
**Post date:** [February 9, 2024, 5:47pm UTC](https://forums.swift.org/t/pitch-synchronous-mutual-exclusion-lock/69889/43 "2024-02-09T17:47:29Z")

</div>

The core functionality of [lifetime-dependent types](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865) is under active design and development, and should be enough to implement a guard type in the nearish future. It would be nice to avoid having the completely unsafe independent `lock` and `unlock` methods if we can hold out until nonescaping types are a reality. While the preconditions for their use are describable, I fear that it'll be difficult for developers to intuit when it's safe to assume that a lock and unlock always happen under the same enclosing borrow, since that isn't a constraint that they're likely to be used to thinking about coming from these sorts of APIs in other languages, and the behavior when you get it wrong is incomprehensible.

---

_[View the full topic](https://forums.swift.org/t/pitch-synchronous-mutual-exclusion-lock/69889)._