<div>Ooh good catch! I have such an issue in my thread-per-jar function, the variable f which is bound in the loop, closed over in the thread run function but executed in a thread! That could explain both the missing values and the duplicates one. I'll report back. </div>

<div><br></div>

<div>Thanks!</div>

<div>Alan</div>

<div class="mailbox_signature">-Alan<br><br>http://alan.ruttenbergs.com/<br></div>

<br><br><div class="gmail_quote"><p>On Sat, Sep 28, 2013 at 11:44 AM, Pascal J. Bourguignon <span dir="ltr"><<a href="mailto:pjb@informatimago.com" target="_blank">pjb@informatimago.com</a>></span> wrote:<br></p><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><p>Mark Evenson <evenson@panix.com> writes:

<br><br>> On Sep 27, 2013, at 9:28 PM, Mark Evenson <evenson@panix.com> wrote:

<br>>

<br>>> 

<br>>> On Sep 27, 2013, at 8:13 PM, "Alan Ruttenberg" <alanruttenberg@gmail.com> wrote:

<br>>> 

<br>>>> Agreed. While the gethash and puthash should independently work,

<br>>>> the combination of the two isn't thread safe. For example two

<br>>>> processes could get the value in the ht before either has a chance

>>> to write back the increment.

<br>>> 

<br>>> A version that only adds to unique keys in the hash table, relying

<br>>> on the HASH-TABLE-COUNT value to indicate successful update.  The

<br>>> keys are the squares of the first eight primes, so the total threads

<br>>> spawned is eight.  the parameter to RUN now indicates how many

<br>>> squares of the given prime basis. But still weirdness, in that the

<br>>> first thread which should increment the keys of the hashtable

<br>>> indexed by the powers of 2 doesn't seem to execute.  Something in my

<br>>> LOOP clause?

<br>>> 

<br>>> <threaded-hash.lisp>

<br>>

<br>> Indeed a faulty understanding of LOOP:

<br>>

<br>> CL-USER> (loop :for n :in '(2 3 5 7 11 13 15 17) :doing (threads:make-thread (lambda () (format t "~A " n))))

<br>>      

<br>> 3 5 7 11 13 15 17 

<br>> 17 NIL

<br>>

> The value of "n" has already been incremented past the first member of the list when the closure is created with LAMBDA, so the thread with "2" never gets executed.

<br>>

<br>> SLIME users: one needs to place the form (setf

<br>> swank:*globally-redirect-io* t) in ~/.swank.lisp to get all the FORMAT

<br>> output in the REPL buffer.  Otherwise look in the corresponding

<br>> *inferior-lisp* buffer.

<br>>

<br>> So, I guess one should loop over closures that have been correctly

<br>> initialized with the right values in some other manner.  I'd go for

> using DO over LOOP for unless someone can correct my understanding.

> Either that, or I need to follow macro expansions.

<br><br>DO won't help better.  For LOOP, DOTIMES, DOLIST, it's unspecified

<br>whether the variables are new bindings or updated bindings.  But for DO

<br>and DO*, it is specified they're updated.  So while with the former you

<br>had a chance for it to work (not conformingly), you stand no such chance

with DO.

<br><br>What you must write is:

<br><br>    (ql:quickload :bordeaux-threads)

<br><br>    (loop :for n :in '(2 3 5 7 11 13 15 17) 

<br>          :do (let ((n n))

<br>                (bt:make-thread (lambda () (format t "~A " n)))))

<br><br>    (do ((ns  '(2 3 5 7 11 13 15 17) (cdr ns)))

<br>         ((null ns))

<br>      (let ((n (car ns)))

<br>        (bt:make-thread (lambda () (format t "~A " n)))))

<br><br>-- 

<br>__Pascal Bourguignon__

<br>http://www.informatimago.com/

<br><br></p></blockquote></div><br>