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

[Erik Huelsmann]

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. 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).

Bye,


Erik.