Re: some ideas for multithreading support

 > Fully agree - no crashes.
 > However I think it's ok to have undefined behaviour (not a crash) when
 > multiple threads modify the same resource without synchronisation.

I'm not sure what you mean above by undefined behavior.
I'd hope that after two threads do something like
 (setf a 3)  and  (setf a 7)
we could claim that a is either 3 or 7.
And that all other storage locations are unchanged.
That's what I'd call nondeterministic rather than undefined.
But the same would be true if both setf's were protected by the
same lock.

So again, I think the task is to either define what the possible
outcomes are of unlocked simultaneous access if those outcomes
are all considered reasonable, or if not, introduce locking and
describe what outcomes are possible with the locking and also any 
possible consequences of the locking that might affect the user.
For instance, I hope hash table iteration could be described in 
terms of all of the keys in the table at the beginning plus all 
those added during the iteration being ordered somehow, and the 
iteration visiting them in that order (along with the associated
values at the time the key is visited), but skipping those that 
were not in the table (either cause they were deleted earlier 
or not yet added) at the time the iteration reaches their position.  

(BTW, I think that the statement: 
 the iteration visits once every key that was in the table at the 
 beginning of the iteration but never deleted during the iteration, 
 never visits any key that was not in the table at the beginning 
 and not added during the iteration, and visits either once or zero
 times those that were added or deleted during the iteration
is implied by that but fails to guarantee some desired ordering 
properties guaranteed by the more operational description.)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel