Oh, yes, thank you very much for bringing up the issue of threads!<div><br></div><div>I have to mention that they are not thread-safe.  The CL definition does not say whether hash tables are thread-safe since the CL definition has no thread concept.  CCL hash tables are thread-safe.<div>

<br></div><div>Right now, they aren't CLOS instances at all.  It was sort of a little pedagogical point of the exercise that an abstraction doesn't have to be a CLOS object.  This is part of my whole claim that CLOS, unlike, say, CLU, isn't trying to be an encapsulation mechanism.  If you want encapsulation, that's what packages are for.  Java tries to both and ends up with baroque rules about how "protected" interacts with "in different packages".</div>

<div><br></div><div>But Fare pointed out to me that being able to add generic functions specialized on these would be a good thing.  This would mean making them use CLOS not for encapsulation but for genericty.</div><div>

<br></div><div>So maybe there could be a subclass that did the locking.  Java's new collection library also provides basic non-thread-safe collections, and then thread-safe ones built upon them.  Thread-safety costs.  I really ought to measure that, though.</div>

</div>