Re: [swift-evolution] Introducing synthesized locks

[David Smith via swift-evolution]

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 
>  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

Re: [swift-evolution] Introducing synthesized locks

[David Moore via swift-evolution]

Synchronization would indeed be an area of improvement for Swift. I would, 
however, add that the primitive should also work with more than just functions. 
For example, it should play nicely with closures and should most definitely 
work with properties (to synchronize access for a given resource value). 
Furthermore, I would like to suggest a change of name from ‘synchronized’ to 
‘exclusive’, as it fits more tightly with the new exclusivity rules in Swift 4.

On Jun 13, 2017, 1:39 PM -0400, Kevin Nattinger via swift-evolution 
, wrote:
> I'd prefer to see block-scoped synchronization rather than whole-method-only; 
> it gives much more flexibility.
>
> Note that you can use the objc synchronization feature with reference types:
>
> // Or (_ obj:...) if you prefer the label-less objc style)
> func synchronized(on obj: AnyObject, do block: () throws -> Void) rethrows {
>     objc_sync_enter(obj)
>     defer {
>         objc_sync_exit(obj)
>     }
>     try block()
> }
>
> // or synchronized(self)
> synchronized(on: self) {
>     // do something
> }
> try synchronized(on: self) {
>     throw NSError()
> }
>
> Not 100% sure this works with bridged reference types (e.g. Array); 
> definitely doesn't work with Int. Use a dummy NSObject() if needed.
>
> That said, I'd love to see a swift-native solution that works with value 
> types (and doesn't rely on the objc runtime).
>
> > On Jun 12, 2017, at 2:10 AM, Erik Aigner via swift-evolution 
> >  wrote:
> > [...]
> > With synchronized attribute (the semaphore/wait/deferred-signal is 
> > synthesized by Swift automatically)
> >
> > class Obj {
> >
> > synchronized func method() {
> > // semaphore is synthesized automatically, do something…
> > }
> > }
> >
>
> ___
> 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

Re: [swift-evolution] Introducing synthesized locks

[Kevin Nattinger via swift-evolution]

I'd prefer to see block-scoped synchronization rather than whole-method-only; 
it gives much more flexibility.

Note that you can use the objc synchronization feature with reference types:

// Or (_ obj:...) if you prefer the label-less objc style)
func synchronized(on obj: AnyObject, do block: () throws -> Void) rethrows {
objc_sync_enter(obj)
defer {
objc_sync_exit(obj)
}
try block()
}

// or synchronized(self)
synchronized(on: self) {
// do something
}
try synchronized(on: self) {
throw NSError()
}

Not 100% sure this works with bridged reference types (e.g. Array); definitely 
doesn't work with Int. Use a dummy NSObject() if needed.

That said, I'd love to see a swift-native solution that works with value types 
(and doesn't rely on the objc runtime).

> On Jun 12, 2017, at 2:10 AM, Erik Aigner via swift-evolution 
>  wrote:
> [...]
> With synchronized attribute (the semaphore/wait/deferred-signal is 
> synthesized by Swift automatically)
> 
> class Obj {
> 
>   synchronized func method() {
>   // semaphore is synthesized automatically, do something…
>   }
> }
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Introducing synthesized locks

[Beta via swift-evolution]

With a serial queue guarding the function or concurrent queues dumping into a 
serial target queue, DispatchQueue.sync(execute:) can be used as a 
synchronizing primitive suitable for most workflows.  Have you tried exploring 
libDispatch outside of Semaphores?

~Robert Widmann

> On Jun 12, 2017, at 2:10 AM, Erik Aigner via swift-evolution 
>  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

Re: [swift-evolution] Introducing synthesized locks

[Karl Wagner via swift-evolution]

> On 12. Jun 2017, at 11:10, Erik Aigner via swift-evolution 
>  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 does not currently have any special support for concurrency. That will 
undoubtedly come in some future version of Swift, and atomic operations and 
data are pretty common use-cases which I’m sure the community will want covered.

- Karl
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Introducing synthesized locks

[Erik Aigner via swift-evolution]

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