Re: [Chicken-users] set! atomic?
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
Re: [Chicken-users] set! atomic?
From: Bryan Vicknair bryanv...@gmail.com Subject: [Chicken-users] set! atomic? Date: Tue, 4 Jun 2013 19:15:52 -0700 SRFI-18 states: Read and write operations on the store (such as reading and writing a variable, an element of a vector or a string) are not required to be atomic. It is an error for a thread to write a location in the store while some other thread reads or writes that same location. Is it possible to eval a variable that is in an inconsistent state? I understand that if there are a series of set-car! on a list, then a reader may see the list as it is in between any of the set-car! calls. But is it possible that an update to a very large object will ever be interrupted by one thread such that other threads will see a broken version? (use srfi-1) (define foo '(1 2 3)) (thread-start! (make-thread (lambda () (set! foo (iota 1e8) (print foo) 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. cheers felix ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
[Chicken-users] set! atomic?
SRFI-18 states: Read and write operations on the store (such as reading and writing a variable, an element of a vector or a string) are not required to be atomic. It is an error for a thread to write a location in the store while some other thread reads or writes that same location. Is it possible to eval a variable that is in an inconsistent state? I understand that if there are a series of set-car! on a list, then a reader may see the list as it is in between any of the set-car! calls. But is it possible that an update to a very large object will ever be interrupted by one thread such that other threads will see a broken version? (use srfi-1) (define foo '(1 2 3)) (thread-start! (make-thread (lambda () (set! foo (iota 1e8) (print foo) In the above code, will the primordial thread ever print a list that isn't exactly (1 2 3) or (iota 1e8)? The context of my question is that for a small web app I have a hash table that all threads read freely, but they coordinate writes with a mutex. Do I need to also have a read lock? Bryan Vicknair ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] set! atomic?
Yes, many mutate operations are not srfi-18 threads aware, in my (possibly incorrect) experience. Also, just as an FYI, Chicken's SRFI-18 threads are not system threads, and so cannot avail themselves of additional processors. If real parallel operations are your goal then you'll want to look at process forking. posix, posix-shm, posix-semaphore and lolevel's object-evict (or the new protobuf) should be helpful in this regard. -Dan On 13-06-04 07:15 PM, Bryan Vicknair wrote: SRFI-18 states: Read and write operations on the store (such as reading and writing a variable, an element of a vector or a string) are not required to be atomic. It is an error for a thread to write a location in the store while some other thread reads or writes that same location. Is it possible to eval a variable that is in an inconsistent state? I understand that if there are a series of set-car! on a list, then a reader may see the list as it is in between any of the set-car! calls. But is it possible that an update to a very large object will ever be interrupted by one thread such that other threads will see a broken version? (use srfi-1) (define foo '(1 2 3)) (thread-start! (make-thread (lambda () (set! foo (iota 1e8) (print foo) In the above code, will the primordial thread ever print a list that isn't exactly (1 2 3) or (iota 1e8)? The context of my question is that for a small web app I have a hash table that all threads read freely, but they coordinate writes with a mutex. Do I need to also have a read lock? Bryan Vicknair ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
