Re: idea for MT testing

Other concurrency issues than with hashtables can generally occur with
setting non-primitive values which exceed a native word.

eg setting a 64bit value on a 32bit architecture, which is internally split
into two setters.
Or setting unaligned values, which also need to update two words.
But out of my head I don't see such problems, and they can easily fixed by
locks.

Don Cohen <[email protected]> schrieb am Mo., 11. Feb.
2019, 17:19:

>
> I seem to be the one most interested in getting MT to work.
> Sometimes I think maybe the only one interested.
>
> Here's my next idea:
>
> My impression is that developers think the ONLY problem left
> is hashtables.  I propose to test that by replacing hash
> tables with alists.
>
> If that stopped the crashing I'd consider more seriously
> trying to solve the hashing problem.
> Otherwise I's hope to convince one of the current MT experts
> to find (and fix?) whatever other problems I discover, or at
> least help me to do so.
>
> My first question is whether the experts on this list think
> that's a good idea, or have any alternate suggestions.
>
> I was hoping that the hashtable implementation contained a
> special case that used alists for very small tables, and that
> I could convert to alists by simply redefining "very small".
> I started looking at the source in hashtabl.d and so far I
> don't see what I was hoping for.
>
> My second question is (if the first one seems a good idea)
> whether any experts have any advice on the easiest way to
> go about the implementation.
>
>
> _______________________________________________
> clisp-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/clisp-devel
>

_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel