> On Sep 11, 2017, at 9:00 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > On Sep 4, 2017, at 12:18 PM, Pierre Habouzit <[email protected] > <mailto:[email protected]>> wrote: >> Something else I realized, is that this code is fundamentally broken in >> swift: >> >> actor func foo() >> { >> NSLock *lock = NSLock(); >> lock.lock(); >> >> let compute = await someCompute(); <--- this will really break `foo` in >> two pieces of code that can execute on two different physical threads. >> lock.unlock(); >> } >> >> >> The reason why it is broken is that mutexes (whether it's NSLock, >> pthread_mutex, os_unfair_lock) have to be unlocked from the same thread that >> took it. the await right in the middle here means that we can't guarantee it. > > Agreed, this is just as broken as: > > func foo() > { > let lock = NSLock() > lock.lock() > > someCompute { > lock.unlock() > } > } > > and it is just as broken as trying to do the same thing across queues. Stuff > like this, or the use of TLS, is just inherently broken, both with GCD and > with any sensible model underlying actors. Trying to fix this is not worth > it IMO, it is better to be clear that they are different things and that (as > a programmer) you should *expect* your tasks to run on multiple kernel > threads. > > BTW, why are you using a lock in a single threaded context in the first > place??? ;-)
I don't do locks, I do atomics as a living. Joke aside, it's easy to write this bug we should try to have the compiler/analyzer help here for these broken patterns. TSD is IMO less of a problem because people using them are aware of their sharp edges. Not so much for locks. -Pierre > > -Chris > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
