Re: some ideas for multithreading support

Hi,

Don wrote:
>I'm expecting the hash table implementation to do whatever is necessary
>in order to make programs written by users without adding their own
>locks work as I think they are justified in expecting in the presence
>of other threads.
You expect some isolation level better than my A) "don't crash".

>I've been assuming that a package IS a hash table and that when the
>implementation of hash tables is fixed then packages will work.
Not sure, packages may need their own lock to update the package
object. The hash table therein is just one slot. But I've not looked at
actual code, maybe that's all that is needed.

>I don't understand the distinction between A and B.

A) User code calls MAKE-HASH-TABLE, then lets N threads stamp on it.

B) clisp uses hash-table internally, e.g. in CLOS or packages.
Package access ought to be thread-safe, hence clisp will use locks internally.

>[...] Or the user writing a program to
>iterate in one thread while altering the table in another has to add
>locks?  I want this to be unnecessary in order to obtain the guarantee
>I described.
I understood that wish of yours, and that's where A and B collapse: You
don't want a distinction, and even more than that: you don't want
the need for locks just to walk and update hash-tables.
That's OK, and I believe exactly this feature has been on the clisp
wish-list for as long as threads exist.

My idea A was that, until the time when somebody will fulfill this wish, we
can live with minor updates to the current hash table code just good enough
to terminate iteration and to not crash.

>Then an iteration would only have to keep track of the current key,
>right?  It could lock the table in order to find the next key and
>then unlock the table.
Might work. Even if that key has been deleted meanwhile, the CDR of
the list can still point to the former remaining elements
(some of those may well have been deleted since ...).

Alternatively, the hash-table may weakly link to all iterators, so their current
index can be checked. Maybe that's more in line with what Bruno wants:
Check during update that nobody is iterating at another position - even when single-threaded.
That implies that iterating through *PACKAGE*, calling READ/INTERN is likely to fail, ouch!

>My specification says there should be some ordering of the keys that
>were in the table at the start of iteration along with those added
>during the iteration.
Why not: Push new at start, remove anywhere?
That too implies that once you are mid-list, you won't see new elements.

>I think you're saying that you DO have a solution for that
>particular algorithm but you're not satisfied with its performance.
Not at all, I'm sorry. I barely have time to think about LOOP.

>As I said above, I don't know how they work in any detail.  
Neither me. I was just expressing an idea (that Bruno would dislike:)

I apologize for creating such confusion,
	Jörg

------------------------------------------------------------------------------
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