[Ecls-list] hash-table implicit mp:lock

[Matthew Mondor]

Hello,

I noticed that ECL hash tables are automatically thread-synchronized
using a lock.  I was wondering if this was inspired from other
implementations?  Or does ECL itself need this other than for package
hash tables?

Coming from a C world with POSIX threads, I'm used to explicit
synchronization where needed.  This also allows a performance gain
where user code knows no locking is needed (and allow things such as
concurrent read-only lookups).  When reading CLISP's implementation
notes about its experimental thread support, I noticed the following
Hyperspec links to justify that their implementation avoids implicit
synchronization even on hash-tables (despite the standard not
explicitely supporting threads):

3.6 Traversal Rules and Side Effects
18.1.2 Modifying Hash Table Keys

According to those, it seems like a multithreaded implementation would
expect the user to explicitely take precautions against r/w
concurrency...  Of course, internal requirements such as package access,
CLOS, compiler, GC, etc, would however still implicitely use locks
where needed.

It'd also be interesting to hear what more experienced lispers think?
Is it better for threaded CL implementations to prevent users from
shooting themselves in the foot or not?  And is there any significant
historical precedent?

Thanks,
-- 
Matt