International Lisp Conference 2009
Lisp: The Next 50 Years
NavigationUser login |
Proposal: Common Lisp memory model and threadingWhen will changes to a hashtable will affect another thread? How about special variables, alists, plists? What about redefining classes and methods? Java faced these issues early in its development. Some operations were declared thread-safe, others were not. A few flaws were found in the original specification, and JSR 133 was spawned to address them. In 2004, a new section was added to the language specification. Multiple CL implementations now support threads, but each in its own way. Is it time for a unified design effort to be made in the Lisp community?
|
Active forum topicsNew forum topicsSearch |
Yes, memory model needed
I can't speak to the difficulty of retrofitting such a thing, but a memory model spec such as Java's is definitely needed for doing concurrency, IMO
How is it done now?
Yes, you really do need a memory model in the Java sense. I know that getting this right is hard; see Bill Pugh's work, where he finds problems with the original Java model and proposes solutions. (I don't know where this stands now.)
I wonder how the existing Lisp implementations deal with these issues. I've never seen an explicit memory model described for any Common Lisp, but that doesn't mean there aren't any.
BP has fixed the Java model:
BP has fixed the Java model: http://www.cs.umd.edu/~pugh/java/memoryModel/
As a first start
I would take the Java model and see how it applies to CL. For each CL operation that changes shared state, the question must be asked "How should this affect other threads"?
Without a guide, existing implementations deal with these issues using the simple maxim "fix problems as they arise". But there are common patterns. For example, dynamic variables are mapped to thread-local storage, maybe with initial values set by the parent thread. SETF is atomic on simple values such as FIXNUM, CAR, and CDR. etc.
From my view on the sidelines, I seriously doubt anyone has a well-documented CL memory model. Maybe Franz or Lispworks have one locked away somewhere, but its not common knowledge.