[armedbear-devel] CLOS thread safety

[Erik Huelsmann]

Hi David,

On Tue, Apr 27, 2010 at 8:56 PM, David Kirkman <dkirkman at ucsd.edu> wrote:
> On Tue, Apr 27, 2010 at 11:37 AM, Erik Huelsmann <ehuels at gmail.com> wrote:
>>
>> Yesterday, I took a little time to look at the issue you mention. You
>> said with 1 big "lock around everything" it all worked. Where did you
>> put that lock? I tried putting some locks in a number of places
>> (educated guesses), but nothing helped so far. I don't have data
>> regarding the stack trace you see when running into this issue - there
>> wasn't enough time for it.
>>
>
> I redefined make-instance and slot-value.  This seems to fix things, or
> at least greatly reduce the frequency of problems.   (I'm still having an
> occasional MOP::NAME error, but I can't reproduce it).  Other than
> make-instance on slot-value, my code uses a lot of generic functions.
>
>
> (defvar *skye-clos-lock* (make-hash-table))
>
> (defmacro make-instance (&body body)
>  `(progn
>     (threads:with-thread-lock (*skye-clos-lock*)
>       (common-lisp:make-instance , at body))))
>
> (defun slot-value (&rest args)
>  (threads:with-thread-lock (*skye-clos-lock*)
>    (apply #'common-lisp:slot-value args)))
>
> (defun set-slot-value (c slot val)
>  (threads:with-thread-lock (*skye-clos-lock*)
>    (setf (common-lisp:slot-value c slot) val)))
>
> (defsetf slot-value set-slot-value)
>
>
> Can you reproduce the error?

Yes! Absolutely, I'm able to reproduce reliably (on a Core2 Duo). I
just was inserting locks *inside* make-instance.

>  The second snippet that just exercises
> make-instance is more reliable at failing.  Do you want a stack trace?

If you can get a stacktrace of the failing thread easily, yes, please!

Bye,


Erik.