From: <don...@is...> - 2004-06-16 19:50:56
|
> What I think needs to be done first, before digging into the implementation, > is to examine _all_ of Common Lisp, from the ground up, and specify the > multithreading behaviour of each function and each data structure. I'm happy to see this, after a long history of suggestions of form "start fixing the sigsegv's" ! Note that all of CL is not enough. Interaction with FFI (and foreign threads) is particularly important to specify. Last I heard, ACL did not allow lisp threads to run at the same time as any foreign code. > CMUCL and SBCL have no usable docs about multithreading. ACL and LW may > look better. I've never seen any. If anyone knows where to find them I would be interested in a reference. I also wonder about lispm/symbolics docs. I never saw any of those either. I don't think lispms ever had to deal with multiple processors, but I still bet those docs would be useful. In the absense of docs one might at least hope to reconstruct (hallucinate?) something from the code. |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2004-07-05 11:36:17
|
Hi, here's food for thinking/reading for all of you who are looking IMHO too deep into automagic write locks and multi-threading safety etc. Many programming languages I know -- inluding Common Lisp -- do not allow to map/walk/iterate through a hash table and meanwhile modify any other key than the current one. That means (maphash #'(lambda (k v) (random-user-func table k v)) table) is inherently dangerous. Nevertheless, and despite arbitrary user-defined code being callable my iterators, I've never ever seen a programm proof where one assesses that the hashtable iteration restriction will not be violated. What I mean to criticise is how can people argue about safety w.r.t. threads when hash-table are not even safe without them? Please think about how the above restriction made it into many language definitions. My point is: please, avoid the "too much" syndrom. Too me, write or read locks as discussed in clisp-devel in June, have a flavour of this wish for too much automated protection, which I believe to be neither realistic nor practical. BTW, Andreas Thiele suggested peeking at CormanLisp for code/howto. Roger Corman has a paper somewhere about adding threads to = his system. I remember him talking about code generation issues, i.e. the native code compiler must maintain a few additional invariants when a system has threads. I don't believe this would help for a pure bytecode system. I read his paper long ago. Regards, J=F6rg H=F6hle |
From: Denis B. <db...@st...> - 2004-07-06 11:42:00
|
In general, I agree with J=F6rg. wrt to MT, I think what should be done=20= first is to create a mapping (i.e. set of functions/macros) to pthreads=20= from lisp. This way the user can easily do his own locking. Then I=20 think the issues will present themselves more clearly as to how to=20 "automate" the locking like we have been talking about. First question, is the GC thread-safe? On 05 Jul 2004, at 07.36, Hoehle, Joerg-Cyril wrote: > Hi, > > here's food for thinking/reading for all of you who are looking IMHO > too deep into automagic write locks and multi-threading safety etc. > > Many programming languages I know -- inluding Common Lisp -- do not > allow to map/walk/iterate through a hash table and meanwhile modify > any other key than the current one. > > That means > (maphash #'(lambda (k v) (random-user-func table k v)) table) > is inherently dangerous. > > Nevertheless, and despite arbitrary user-defined code being callable > my iterators, I've never ever seen a programm proof where one assesses > that the hashtable iteration restriction will not be violated. > > What I mean to criticise is how can people argue about safety > w.r.t. threads when hash-table are not even safe without them? > > Please think about how the above restriction made it into many > language definitions. > > My point is: please, avoid the "too much" syndrom. > > Too me, write or read locks as discussed in clisp-devel in June, have > a flavour of this wish for too much automated protection, which I > believe to be neither realistic nor practical. > > BTW, Andreas Thiele suggested peeking at CormanLisp for > code/howto. Roger Corman has a paper somewhere about adding threads to=20= > his > system. I remember him talking about code generation issues, i.e. the > native code compiler must maintain a few additional invariants when a > system has threads. I don't believe this would help for a pure > bytecode system. I read his paper long ago. > > Regards, > J=F6rg H=F6hle > > > ------------------------------------------------------- > This SF.Net email sponsored by Black Hat Briefings & Training. > Attend Black Hat Briefings & Training, Las Vegas July 24-29 - > digital self defense, top technical experts, no vendor pitches, > unmatched networking opportunities. Visit www.blackhat.com > _______________________________________________ > clisp-devel mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-devel > > -- Denis Bueno PGP: http://pgp.mit.edu:11371/pks/lookup?search=3D0xA1B51B4B&op=3Dindex "Acquaintance, n.: A person whom we know well enough to borrow from,=20 but not well enough to lend to." - Ambrose Bierce |
From: Andreas T. <and...@te...> - 2004-06-24 07:10:57
|
>Last I heard, ACL did not allow lisp threads to run at the >same time as any foreign code. I think Lispworks doesn't either. Currently I am testing on this. Besides, I just noticed Corman Lisp kernel sources are available from www.cormanlisp.com. What about looking at these sources? Code seems to be rather compact because it is a 'windows only' implementation. Andreas |
From: Denis B. <db...@st...> - 2004-06-24 18:41:18
|
On 16 Jun 2004, at 15.49, Don Cohen wrote: >> CMUCL and SBCL have no usable docs about multithreading. ACL and LW >> may >> look better. > > I've never seen any. If anyone knows where to find them I would be > interested in a reference. > I also wonder about lispm/symbolics docs. I never saw any of those > either. I don't think lispms ever had to deal with multiple > processors, but I still bet those docs would be useful. OpenMCL has a doc about their native threads: http://openmcl.clozure.com/Doc/threads.html Would using this as a guide be a good idea? Initially I was thinking about providing a lisp API for pthreads; so you could do something like: (defparameter *shared-input* '()) (defparameter *shared-output* (make-hash-table)) (defun thread-1-fn () (let ((key nil) (val nil)) (mt:with-mutex-lock (*input-mutex-var*) ;; read from *shared-input* ;; this macro of course would have an UNWIND-PROTECT to ;; free the resource on error, or whenever the scope goes away ) (mt:with-mutex-lock (*output-mutex-var*) ;; assume key and val were properly set in the above form (setf (gethash key *shared-resource*) val)))) (defparameter *input-mutex-var* nil) (defparameter *output-mutex-var* nil) (mt:pthread-mutex-init *input-mutex-var*) (mt:pthread-mutex-init *input-mutex-var*) (let ((t1-id (mt:pthread-create #'thread-1-fn))) ;; in this thread you would do the "producing", putting stuff ;; into *input-mutex-var*, e.g. (mt:with-mutex-lock (*input-mutex-var*) (while (space-available-p *shared-input*) ;; put something in *shared-input* ))) Which would essentially map down to the obvious pthread_* functions. Do you think this is a good/terrible idea? -- Denis Bueno PGP: http://pgp.mit.edu:11371/pks/lookup?search=0xA1B51B4B&op=index "Clothes make the man. Naked people have little or no influence on society." - Mark Twain |