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 ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
