All constant-time procedures and operations provided by Racket are
thread-safe because they are atomic. For example, set! assigns to a variable
as an atomic action with respect to all threads, so that no thread can see a
“half-assigned” variable. Similarly, vector-set! assigns to a vector
atomically. The hash-set! procedure is not atomic, but the table is
protected by a lock; see Hash Tables for more information. Port operations
are generally not atomic, but they are thread-safe in the sense that a byte
consumed by one thread from an input port will not be returned also to
another thread, and procedures like port-commit-peeked and write-bytes-avail
offer specific concurrency guarantees.
It mentions that hash table assignment is not thread-safe, however if you then go to the hash table page[1], it says this:
A mutable hash table can be manipulated with hash-ref, hash-set!, and
hash-remove! concurrently by multiple threads, and the operations are
protected by a table-specific semaphore as needed. Three caveats apply,
however [...]
In other words, Racket already handles everything, according to the docs. If you're ever worried enough, or run into any problems, it's not hard to wrap it in `atomic` yourself. I'd rather not have the cost of `atomic-invoke` for every assignment, especially if you run all your code in one thread (like I do).
By the way, Nu doesn't use `set!` for global assignment, so I'm not sure if global assignment in Nu is thread-safe or not. But I'd assume it is, since I think `namespace-set-variable-value!` is constant-time.
This ensures that car.foo, (bar), and (scar gs1 val) all happen without interference in between. I suspect Racket at most protects those on an individual basis.
"In pg-Arc, '= on a variable is 'assign without 'atomic. Where 'atomic comes in is when there's a setforms thing to worry about."
I am aware. It still seems to me that if you're dealing with threads, you should wrap assignment in atomic yourself if you're worried about such things. Code that doesn't deal with threads shouldn't have to use atomic.
Perhaps there should be an `a=` macro that's just like `=` but it calls `atomic`. Hm... I wonder... would it be possible to detect whether code is running in the default thread and if not, automatically wrap it in atomic...? May be more trouble than it's worth, though.
That's what I think. Anyone who cares can say (atomic:= ...) or (atomic:zap ...), so I only see a couple of reasons why we'd want to have the 'atomic implicit:
- We want to use it all the time anyway. (I doubt it, but it's hard to tell. I haven't used threads, and therefore I've never bothered to find a way to squeeze utility out of it.)
- There are people who do care, and they'd be better off if the people who didn't care still used 'atomic by accident. (Again, it's hard for me to tell if this is true.)
