libera/#sicl - IRC Chatlog
Search
2:16:52
hayley
Bike: One thought on the WSCL concurrency specification: would it be hard to specify that, in case of concurrent writes to a place, the implementation may choose an arbitrary write operation to be the "associated write operation"? Programs with data races would exhibit (more) non-determinism, but they would still be safe; in that a data race cannot turn one's coffee machine on, or forge references to objects.
2:18:13
hayley
I believe any cache coherent system created while I was alive does not allow for "tearing", and it is just on the implementation to not unbox in a way where multiple separate writes are required for some operation. And no implementations that I know of do anything like that.
2:18:58
minion
drakonis: WSCL: Well-Specified Common Lisp. Pronounce it as "whistle". A project to revise the Common Lisp standard in a non-controversial way. See https://github.com/s-expressionists/wscl
2:20:24
Bike
it's been long enough since i thought about it that i don't remember quite what "associated write" means, but limiting the effects to wonky data would be good if it can be done
2:20:38
Bike
for tearing i was thinking of things like i think sbcl has specialized arrays for complexes
2:22:01
hayley
Tearing on arrays that do not contain references is less of a concern for me, but it would be less simple to specify that only boxed arrays must always read a write.
2:24:22
hayley
drakonis: For the most part. The most famous incompatibility is the handling of PROG2.
2:25:47
drakonis
https://github.com/s-expressionists/wscl/tree/main/wscl-issues/proposed there are the proposed changes?
2:27:37
moon-child
Bike: more bikeshedding: I think ATOMIC-UPDATE should return two values: the old value, and the new one
2:41:03
Bike
yeah, i guess it should return the old value somehow, since it might be impossible to get otherwise
2:47:02
Bike
ok i see what you mean about the associated write operation, hayley. when you say "arbitrary" you mean another write to the same place, just maybe not one of the conflicting ones? because more arbitrary than that seems like it could result in froging
2:48:17
hayley
I mean e.g. initially *x* = 0, T1 runs (setf *x* 1), T2 runs (setf *x* 2), T3 runs (progn (join-thread T1) (join-thread T2) *x*) which returns either 1 or 2
2:52:45
hayley
So the writes *x* <- 1 and *x* <- 2 are concurrent and thus conflict, but we choose an arbitrary write to make the associated write operation. Or another way of wording it is that writes that are not from an ATOMIC or CAS form are relaxed (or unordered?) by default.
2:56:13
Bike
so you're saying *x* could be any of 0, 1, 2 but nothing else? or would values from previous writes to *x* be possible, or writes to other places
2:57:32
hayley
We just don't know which of the two writes T3 will read, because there is no ordering.
3:01:37
Bike
okay, so you're talking about the case where the accesses are not atomic at all? okay. sorry, guess i'm slow tonight
3:02:08
Bike
the only concern i had with saying everything is unordered/whatever by default was the tearing, i think
3:03:11
Bike
though now that i'm thinking about it, i think "unordered" is what everything shared in java is, and if they can manage it maybe it'll work out
3:03:35
hayley
Relaxed writes are still atomic, and don't tear still. So IMO it should be uncontroversial for any boxed place to at least have relaxed writes.
3:04:05
hayley
Yeah, everything is boxed in Java, so normal word writes work for achieving it, best I know.
3:05:30
hayley
...except that longs and doubles may tear according to <https://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.7>. Weird but okay.
3:06:57
Bike
unordered versus relaxed is kind of a hedging thing, by the way. i know actual processors don't actually do anything weaker than relaxed, but i don't know, maybe compiler optimizations could get screwy
3:07:29
hayley
Right. Though I recall Doug Lea(?) mentioning some x86 JVM would implement an atomic write of a long by pushing the long into the x87, and then popping into memory.