[armedbear-devel] [PATCH] Support for SYNCHRONIZED blocks (and company)

[Alessio Stalla]

On Thu, Jul 9, 2009 at 11:56 AM, Erik Huelsmann<ehuels at gmail.com> wrote:
> On Thu, Jul 9, 2009 at 11:51 AM, Alessio Stalla<alessiostalla at gmail.com> wrote:
>> On Thu, Jul 9, 2009 at 10:53 AM, Erik Huelsmann<ehuels at gmail.com> wrote:
>>> On Thu, Jul 9, 2009 at 7:40 AM, Mark Evenson<evenson at panix.com> wrote:
>>>> Erik Huelsmann wrote:
>>>>>
>>>>> The patch...
>>>>>
>>>>> On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmann<ehuels at gmail.com> wrote:
>>>>>>
>>>>>> Based on discussion earlier this week, I'd like the following patch to
>>>>>> get committed to our trunk.
>>>>>>
>>>>>> It introduces a new block statement
>>>>>>
>>>>>>  SYNCHRONIZED-ON <object>
>>>>>>   body
>>>>
>>>> And, just to be clear, this patch meets Anton Vodonosov's caution that
>>>> "synchronized" has semantics associated with memory synchronization because
>>>> it implements SYNCHRONIZED-ON directly in the bytecode compiler just as Java
>>>> (the language) does, right?  So the whole "happens-before" semantics
>>>> mentioned in the JLS should be met?
>>>
>>> Exactly: I built the compiler conforming to the JVM spec section on
>>> "compiling for the JVM" which discusses the Java 'synchronized'
>>> statement compilation. So, yes.
>>
>> Great work!
>>
>>> The only question I asked myself when I woke up this morning is:
>>>
>>> Should the symbols in this patch not be added to the JAVA package, as
>>> they are designed to "provide access to the Java functionality"?
>>
>> Hmm, you have a point. Perhaps they should be homed and external in
>> JAVA, but imported in THREADS and re-exported from there.
>>
>>> I still think the Gates implementation should be in the threads package, though.
>>>
>>>
>>> I really liked Alessio's suggestion to use javaInstance() to lock on.
>>> That increases interoperability. Alessio, your CON with respect to
>>> fixnums is not justified, IMO, because in general, you can't expect
>>> numbers to remain the same object at any time, according to the spec.
>>> (The same is true, btw, if you synchronize on the Fixnum itself: the
>>> compiler may box the fixnum in order to create a synchronized-on
>>> object)
>>
>> Ok, point taken, but my CON was meant to be more general, because
>> javaInstance() is not guaranteed to always return the same instance
>> even if the LispObject on which it is called has not changed its
>> internal state. Still, it probably does for most objects which I
>> expect to be typically used as locks (symbols, strings? not sure,
>> JavaObjects, ...), so it's just a matter of figuring out which objects
>> are "safe" and which aren't (and maybe document those ;)
>
> I'm working on an SAP implementation within my company now and what I
> learned there:
>
> Don't ever overload meanings.

I recognize profound wisdom in those words :)

> So, maybe, if we want to query a LispObject for its lockable instance, we may need a
> LispObject.lockableInstance() method. In case of a JavaObject, it
> would return an Object; in case of a LispObject it would return
> itself, maybe there are other special cases (such as strings).

That's a very sensible idea imho. We could define lockableInstance()
to be the same as javaInstance() in the general case, and override it
in special cases to either return an object, guaranteed to stay the
same for the entire lifetime of the Lisp object on which
lockableInstance() has been called, or throw an exception, say
NonLockableObjectException (e.g. for numbers). Generally the guideline
would be: if class X overrides javaInstance(), check wheter it should
override lockableInstance() too in order preserve its semantics.

Bye,
Alessio