Le 17 févr. 2017 à 15:08, John McCall via swift-evolution <swift-evolution@swift.org> a écrit : > > We don't have an initial implementation yet, sorry. I'm sure it'll vary a > lot by the application. My hope is that it'll just be a few extra non-atomic > loads and stores around every access, but it's possible that we'll need to > make at least one of those an atomic exchange because it's legal for multiple > threads to read concurrently. It hinges in part on how comfortable we are > with allowing conflicts to escape dynamic detection in complex concurrent > cases.
I think the idea of dynamic bookkeeping state is pretty great, and, in particular, not having to be exact about the state in the presence of concurrent access is a nice way to make it lightweight. The way I read the manifesto, the bookkeeping field would work like this: (a) Thread 1 sets bookkeeping state to read, saves previous state (unaccessed) (b) Thread 2 sets bookkeeping state to read, saves previous state (read) (c) Thread 1 ends access, restores state to unacceseed -- too early, but whatever! (d) Thread 2 ends access, restores state to read? No, you NEVER restore a read. If you never restore a previously saved "read" state, then you'll never get stuck in a "read" state even if the restore order is wrong (like it is here, because of the multiple threads). In this scenario, thread 2 could also restore the state to "unaccessed" instead of doing that conditionally on the saved state. In general however, for reentrant functions to keep single-thearded bookkeeping always exact, setting the state to "unaccessed" has to be conditional to the saved state being the same. If (a) and (b) are not atomic exchanges, a third thread could write a "modify" state during the non-atomic writing of your "read" state, which would make the overlap of the two incompatible accesses undetected. With atomic exchanges in (a) and (b), an incorrect "modify" can only pass undetected during the time between (c) and (d). If by chance (c) and (d) were to occur in reverse order (making it proper nesting time-wise), an incorrect "modify" between the two would become detectable. This is all very interesting. -- Michel Fortin https://michelf.ca _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
