In the above code, will the primordial thread ever print a list that
isn't exactly (1 2 3) or (iota 1e8)?
The assignment itself is fully atomic, as is the destructive
modification of any single data-cell like pair-cells, vector-elements
or record-structure slots.
Even so, code that uses something like a hash-table should have ALL
accesses protected by the same mutex.
I don't know the precise details of Chicken's hash table implementation,
but it's a well-known problem in similar situations in other
environments when a writing thread is interrupted during a resizing of
the hash table (even though any given data cell may be atomic, the
resizing of the hash table will involve many of them with inconsistent
intermediate states), then readers may see the hash table in very crazy
states.
I think I've read an article about just this happening with Java hash
tables, from memory. Readers ended up with a seemingly infinite list of
elements inside a single hash-table bucket due to the chain being
updated while being read, perhaps? It would certainly be easy to see it
missing some or all of its elements, however.
ABS
--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
_______________________________________________
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users
