From: David E. Young
Subject: Atomicity and MP environments
Date: 
Message-ID: <3AF815D0.C3B1CF19@nc.rr.com>
Greetings. I'm building a sample application that will exercise LISA's
(http://lisa.sourceforge.net) multi-threading support, and am wondering
about the behavior of slot access within such an environment. In
particular, I'm curious as to whether I can safely bind slots of certain
types (integer, instance, etc.) without some form of mutex protection
[let's assume that doing so in my application is harmless; I only want
to ensure I don't get "partial" results ].

I realize that MP is not part of the CL standard, but I'm wondering if
anyone has a feel for this behavior with various Lisp implementations.
For example, the Java standard (as I understand it) guarantees that
variables of certain types (int, reference, char, etc.) can be accessed
(read, set) atomically. In other words, accessing variables of certain
types will not yield "partial" or incomplete results. How do the various
Lisp implementations behave? Is it simply not safe to make any
assumptions? Is there a well-established Lisp "pattern" for protecting
slot access? A few different approaches come to mind, all equally good I
suppose.

Sorry. I probably know the answer to this question -- "you can do this
in implementation X but it's not portable" -- but I wanted to hear from
you folks. Thanks for the time.

Regards,

--
-----------------------------------------------------------------
David E. Young
········@computer.org           (defun real-language? (lang)
http://lisa.sourceforge.net       (eq lang 'LISP))

"But all the world understands my language."
  -- Franz Joseph Haydn (1732-1809)

From: Shannon Spires
Subject: Re: Atomicity and MP environments
Date: 
Message-ID: <svspire-5FDAAC.18015711052001@news.sandia.gov>
In article <·················@nc.rr.com>, ·······@nc.rr.com (David E. 
Young) wrote:

> ... In
> particular, I'm curious as to whether I can safely bind slots of certain
> types (integer, instance, etc.) without some form of mutex protection
> [let's assume that doing so in my application is harmless; I only want
> to ensure I don't get "partial" results ].
> 
> I realize that MP is not part of the CL standard, but I'm wondering if
> anyone has a feel for this behavior with various Lisp implementations.
> For example, the Java standard (as I understand it) guarantees that
> variables of certain types (int, reference, char, etc.) can be accessed
> (read, set) atomically. In other words, accessing variables of certain
> types will not yield "partial" or incomplete results. How do the various
> Lisp implementations behave? Is it simply not safe to make any
> assumptions? Is there a well-established Lisp "pattern" for protecting
> slot access? A few different approaches come to mind, all equally good I
> suppose.

Lisp implementations that provide MP also provide the macros 
without-interrupts and/or without-scheduling, to force atomicity.
Locks can also be used to protect individual resources such
as CLOS instances. Of course, all your threads that use such
objects need to cooperate with your locking protocol. Without-interrupts
is best for test-and-set operations that are very quick; locks
are better for more involved computations because they don't monopolize
the scheduler.

Shannon Spires
·······@remove-this.nmia.com
From: Tim Bradshaw
Subject: Re: Atomicity and MP environments
Date: 
Message-ID: <nkjitj42mnz.fsf@tfeb.org>
Shannon Spires <·······@remove-this.nmia.com> writes:

> 
> Lisp implementations that provide MP also provide the macros 
> without-interrupts and/or without-scheduling, to force atomicity.
> Locks can also be used to protect individual resources such
> as CLOS instances. Of course, all your threads that use such
> objects need to cooperate with your locking protocol. Without-interrupts
> is best for test-and-set operations that are very quick; locks
> are better for more involved computations because they don't monopolize
> the scheduler.
> 

Either of the WITHOUT-x macros are also terrible style except in
pretty special cases: consider an implementation on a large
multiprocessor.  A much better approach to this kind of thing, where
you don't want an explicit lock, is a SYNCHRONIZED macro which says
that for *this* bit of code only one thread can be running it at once
(although they can be running any other code).  You can implement
SYNCHRONIZED in terms of a hidden lock which protects the bit of code
concerned (I have an implementation which runs on several platforms if
anyone cares).  It's wonderful that CL is powerful enough to implement
this.

--tim
From: David E. Young
Subject: Re: Atomicity and MP environments
Date: 
Message-ID: <3B0000B3.DA1CC95@computer.org>
Tim Bradshaw wrote:

> Either of the WITHOUT-x macros are also terrible style except in
> pretty special cases: consider an implementation on a large
> multiprocessor.  A much better approach to this kind of thing, where
> you don't want an explicit lock, is a SYNCHRONIZED macro...

I decided to take a similar approach, via the use of a SYNCHRONIZABLE mixin
and a SYNCHRONIZED macro. I'd be interested in seeing your solution.

Regards,

--
-----------------------------------------------------------------
David E. Young
········@computer.org           (defun real-language? (lang)
http://lisa.sourceforge.net       (eq lang 'LISP))

"But all the world understands my language."
  -- Franz Joseph Haydn (1732-1809)
From: Sungwoo Lim
Subject: Re: Atomicity and MP environments
Date: 
Message-ID: <140520011630392196%sungwoo@cad.strath.ac.uk>
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org>
wrote:

> Either of the WITHOUT-x macros are also terrible style except in
> pretty special cases: consider an implementation on a large
> multiprocessor.  A much better approach to this kind of thing, where
> you don't want an explicit lock, is a SYNCHRONIZED macro which says
> that for *this* bit of code only one thread can be running it at once
> (although they can be running any other code).  You can implement
> SYNCHRONIZED in terms of a hidden lock which protects the bit of code
> concerned (I have an implementation which runs on several platforms if
> anyone cares).  It's wonderful that CL is powerful enough to implement
> this.
> 
> --tim

Hello,

Can I see the SYNCRONIZED macro?
Does it works on MCL?
Thanks, :)

Sungwoo
From: Tim Bradshaw
Subject: Re: Atomicity and MP environments
Date: 
Message-ID: <nkjd79b3num.fsf@tfeb.org>
Sungwoo Lim <·······@cad.strath.ac.uk> writes:

> Can I see the SYNCRONIZED macro?

I will post it when I'm near the machine it's on (not
net-connected...).

> Does it works on MCL?

No, but it could easily.  It needs to know how to make a lock, lock it
and unlock it basically.

Actually I think it defines a class called LOCKABLE which is a wrapper
around the native locking substrate, but it doesn't define any real
operations on that other than being able to give them to SYNCHRONIZED
(SYNCHRONIZED without a LOCKABLE argument works by inventing a secret
one and making it all work with MAKE-LOAD-FORM...).  I had (have) a
scheme for extending it to provide enough operations but I haven't.

--tim
From: Sungwoo Lim
Subject: Re: Atomicity and MP environments
Date: 
Message-ID: <140520011844518982%sungwoo@cad.strath.ac.uk>
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org>
wrote:

> Sungwoo Lim <·······@cad.strath.ac.uk> writes:
> 
> > Can I see the SYNCRONIZED macro?
> 
> I will post it when I'm near the machine it's on (not
> net-connected...).
> 
> > Does it works on MCL?
> 
> No, but it could easily.  It needs to know how to make a lock, lock it
> and unlock it basically.
> 
> Actually I think it defines a class called LOCKABLE which is a wrapper
> around the native locking substrate, but it doesn't define any real
> operations on that other than being able to give them to SYNCHRONIZED
> (SYNCHRONIZED without a LOCKABLE argument works by inventing a secret
> one and making it all work with MAKE-LOAD-FORM...).  I had (have) a
> scheme for extending it to provide enough operations but I haven't.
> 
> --tim

I will wait delightly. :)
Thanks,

Sungwoo