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 next to that a number of functions:
object-wait <object> &optional timeout object-notify <object> object-notify-all <object>
So, what's the verdict?
Anyway, I plan on including some simple test cases, but ofcourse, if someone feels like doing so, please feel free!
Bye,
Erik.
The patch...
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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 next to that a number of functions:
object-wait <object> &optional timeout object-notify <object> object-notify-all <object>
So, what's the verdict?
Anyway, I plan on including some simple test cases, but ofcourse, if someone feels like doing so, please feel free!
Bye,
Erik.
On Thu, Jul 9, 2009 at 12:50 AM, Erik Huelsmannehuels@gmail.com wrote:
The patch...
Looks good. If I read it correctly, you establish an exception handler around the synch block, which takes care of releasing the lock if an exception occurs. Right?
On Wed, Jul 8, 2009 at 11:50 PM, Erik Huelsmannehuels@gmail.com wrote:
The patch...
One thing to consider: why not call javaInstance() on LispObjects to obtain the lock object, instead of using the LispObject itself?
Pros: JavaObjects would be unwrapped and thus it could be possible to share a lock with Java code. javaInstance() returns the LispObject itself in most other cases.
Cons: "most" other cases is not good enough. E.g. for Fixnums, it is possible if I understand it correctly that two subsequent calls to javaInstance() will yield two different Integer instances and this is Very Bad.
Maybe instead of always calling javaInstance(), you could test for JavaObjects and call it only in that case. Thoughts?
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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 next to that a number of functions:
object-wait <object> &optional timeout object-notify <object> object-notify-all <object>
So, what's the verdict?
Anyway, I plan on including some simple test cases, but ofcourse, if someone feels like doing so, please feel free!
Bye,
Erik.
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Erik Huelsmann wrote:
The patch...
[…]
The patch creates a new package "THREADS", which I will move the new Gates implementation into once Erik commits unless anyone objects. Actually, I think the Gates functionality can be implemented on top of (i.e. as pure Lisp) the new primitives introduced in this patch, which I will think about as well.
I might suggest that we use "MP" (i.e. multiprocessing) as a nickname for this package as a shortcut convenience.
Erik Huelsmann wrote:
The patch...
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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?
On Thu, Jul 9, 2009 at 7:40 AM, Mark Evensonevenson@panix.com wrote:
Erik Huelsmann wrote:
The patch...
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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.
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"?
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)
Bye,
Erik.
On Thu, Jul 9, 2009 at 10:53 AM, Erik Huelsmannehuels@gmail.com wrote:
On Thu, Jul 9, 2009 at 7:40 AM, Mark Evensonevenson@panix.com wrote:
Erik Huelsmann wrote:
The patch...
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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 ;)
Bye! Ale
On Thu, Jul 9, 2009 at 11:51 AM, Alessio Stallaalessiostalla@gmail.com wrote:
On Thu, Jul 9, 2009 at 10:53 AM, Erik Huelsmannehuels@gmail.com wrote:
On Thu, Jul 9, 2009 at 7:40 AM, Mark Evensonevenson@panix.com wrote:
Erik Huelsmann wrote:
The patch...
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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.
On Thu, Jul 9, 2009 at 11:56 AM, Erik Huelsmannehuels@gmail.com wrote:
On Thu, Jul 9, 2009 at 11:51 AM, Alessio Stallaalessiostalla@gmail.com wrote:
On Thu, Jul 9, 2009 at 10:53 AM, Erik Huelsmannehuels@gmail.com wrote:
On Thu, Jul 9, 2009 at 7:40 AM, Mark Evensonevenson@panix.com wrote:
Erik Huelsmann wrote:
The patch...
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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
On Thu, Jul 9, 2009 at 11:56 AM, Erik Huelsmannehuels@gmail.com wrote:
On Thu, Jul 9, 2009 at 11:51 AM, Alessio Stallaalessiostalla@gmail.com wrote:
On Thu, Jul 9, 2009 at 10:53 AM, Erik Huelsmannehuels@gmail.com wrote:
On Thu, Jul 9, 2009 at 7:40 AM, Mark Evensonevenson@panix.com wrote:
Erik Huelsmann wrote:
The patch...
On Wed, Jul 8, 2009 at 11:49 PM, Erik Huelsmannehuels@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'll start by adding them to JAVA. Then, we can see how this can be imported and exported from THREADS too, taking the autoloader mechanism into account.
Bye,
Erik.
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Erik Huelsmann -
Mark Evenson -
Ville Voutilainen