It's relatively unlikely that Swift's concurrency model, once it gains one,
will look all that similar to Objective-C's. For example*, if Swift were to
adopt a shared-nothing model where heap storage was per-thread and could only
be accessed by another thread by copying or moving the value to its heap, then
a 'synchronized' construct wouldn't be applicable. Until Swift does have a
concurrency model, it's probably best to focus on library-level solutions like
libdispatch.
David
*and this is just an example, there haven't been any concrete proposals for a
direction on concurrency beyond a few old speculative drafts you can find in
the repository
> On Jun 12, 2017, at 2:10 AM, Erik Aigner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> In my day to day tasks, synchronization primitives are used quite often. ObjC
> had the @synchronized attribute for methods. I didn’t find anything about
> this in swift evolution, so I thought i bring it up here. I think it would
> quite easily be possible to introduce a synchronized qualifier for
> struct/class objects that automatically synthesize a semaphore variable on
> the object and use it to lock said method. Here is an example of how that
> would work
>
> Without the synchronized attribute (code written in mail, not compiled):
>
> class Obj {
>
> private let sema = DispatchSemaphore(value: 1)
>
> func synchronizedMethod() {
> sema.wait()
> defer {
> sema.signal()
> }
> // do something...
> }
> }
>
> With synchronized attribute (the semaphore/wait/deferred-signal is
> synthesized by Swift automatically)
>
> class Obj {
>
> synchronized func method() {
> // semaphore is synthesized automatically, do something…
> }
> }
>
>
> Cheers,
> Erik
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
