chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] set! atomic?


From: Dan Leslie
Subject: Re: [Chicken-users] set! atomic?
Date: Tue, 04 Jun 2013 20:15:55 -0700
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/chicken-users




reply via email to

[Prev in Thread] Current Thread [Next in Thread]