(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.0001))))
For times between 0 and 0.0001 this appears to hang indefinitely. No problem with times above 0.001.
The context is the new timeout option for bordeaux-threads:condition-wait,
https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp#...
1.3.0-dev-svn-14623 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
Best, lmj
Hi James,
My thinking is that the wait time is being rounded to zero, which might be used internally by Java to encode an indefinite wait.
Does the patch below work for you?
Bye,
Erik.
Index: LispThread.java =================================================================== --- LispThread.java (revision 14464) +++ LispThread.java (working copy) @@ -1004,11 +1004,12 @@ };
+ private static DoubleFloat factor1000 = new DoubleFloat(1000); + public static final long javaSleepInterval(LispObject lispSleep) - { double d = - checkDoubleFloat(lispSleep.multiplyBy(new DoubleFloat(1000))).getValue(); + checkDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue(); if (d < 0) type_error(lispSleep, list(Symbol.REAL, Fixnum.ZERO));
@@ -1015,6 +1016,17 @@ return (d < Long.MAX_VALUE ? (long) d : Long.MAX_VALUE); }
+ public static final int javaSleepNanos(LispObject lispSleep) + { + double d = // d contains millis + checkDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue(); + double n = d*1000000; // n contains nanos + d = 1.0e6*((long)d); // convert rounded millis to nanos + n = n - d; // retain nanos not in millis + + return (n < Integer.MAX_VALUE ? (int) n : Integer.MAX_VALUE); + } + @DocString(name="sleep", args="seconds", doc="Causes the invoking thread to sleep for SECONDS seconds.\n"+ "SECONDS may be a value between 0 1and 1.") @@ -1025,7 +1037,8 @@ {
try { - Thread.sleep(javaSleepInterval(arg)); + Thread.sleep(javaSleepInterval(arg), + javaSleepNanos(arg)); } catch (InterruptedException e) { currentThread().processThreadInterrupts(); @@ -1208,7 +1221,8 @@
{ try { - object.lockableInstance().wait(javaSleepInterval(timeout)); + object.lockableInstance().wait(javaSleepInterval(timeout), + javaSleepNanos(timeout)); } catch (InterruptedException e) { currentThread().processThreadInterrupts();
On Sat, Feb 1, 2014 at 2:54 PM, James M. Lawrence llmjjmll@gmail.comwrote:
(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.0001))))
For times between 0 and 0.0001 this appears to hang indefinitely. No problem with times above 0.001.
The context is the new timeout option for bordeaux-threads:condition-wait,
https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp#...
1.3.0-dev-svn-14623 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
Best, lmj
Hi, this fixes time=0 and time=0.0001, but it still hangs with time=0.000000001 and smaller positive values.
On Sat, Feb 1, 2014 at 11:36 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi James,
My thinking is that the wait time is being rounded to zero, which might be used internally by Java to encode an indefinite wait.
Does the patch below work for you?
Bye,
Erik.
Index: LispThread.java
--- LispThread.java (revision 14464) +++ LispThread.java (working copy) @@ -1004,11 +1004,12 @@ };
- private static DoubleFloat factor1000 = new DoubleFloat(1000);
- public static final long javaSleepInterval(LispObject lispSleep)
- { double d =
checkDoubleFloat(lispSleep.multiplyBy(newDoubleFloat(1000))).getValue();
checkDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue(); if (d < 0) type_error(lispSleep, list(Symbol.REAL, Fixnum.ZERO));@@ -1015,6 +1016,17 @@ return (d < Long.MAX_VALUE ? (long) d : Long.MAX_VALUE); }
- public static final int javaSleepNanos(LispObject lispSleep)
- {
double d = // d contains millischeckDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue();double n = d*1000000; // n contains nanosd = 1.0e6*((long)d); // convert rounded millis to nanosn = n - d; // retain nanos not in millisreturn (n < Integer.MAX_VALUE ? (int) n : Integer.MAX_VALUE);- }
- @DocString(name="sleep", args="seconds", doc="Causes the invoking thread to sleep for SECONDS seconds.\n"+ "SECONDS may be a value between 0 1and 1.")
@@ -1025,7 +1037,8 @@ {
try {
Thread.sleep(javaSleepInterval(arg));
Thread.sleep(javaSleepInterval(arg),- javaSleepNanos(arg)); } catch (InterruptedException e) { currentThread().processThreadInterrupts();
@@ -1208,7 +1221,8 @@
{ try {
object.lockableInstance().wait(javaSleepInterval(timeout));
object.lockableInstance().wait(javaSleepInterval(timeout),javaSleepNanos(timeout)); } catch (InterruptedException e) { currentThread().processThreadInterrupts();On Sat, Feb 1, 2014 at 2:54 PM, James M. Lawrence llmjjmll@gmail.com wrote:
(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.0001))))
For times between 0 and 0.0001 this appears to hang indefinitely. No problem with times above 0.001.
The context is the new timeout option for bordeaux-threads:condition-wait,
https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp#...
1.3.0-dev-svn-14623 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
Best, lmj
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Hi James,
Thanks for confirming that.
What would you consider the best option when the timeout value becomes too close to 0? I see 2:
1. Don't wait. 2. Wait at least 1 ns
Bye,
Erik. On Feb 1, 2014 7:50 PM, "James M. Lawrence" llmjjmll@gmail.com wrote:
Hi, this fixes time=0 and time=0.0001, but it still hangs with time=0.000000001 and smaller positive values.
On Sat, Feb 1, 2014 at 11:36 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi James,
My thinking is that the wait time is being rounded to zero, which might
be
used internally by Java to encode an indefinite wait.
Does the patch below work for you?
Bye,
Erik.
Index: LispThread.java
--- LispThread.java (revision 14464) +++ LispThread.java (working copy) @@ -1004,11 +1004,12 @@ };
- private static DoubleFloat factor1000 = new DoubleFloat(1000);
- public static final long javaSleepInterval(LispObject lispSleep)
- { double d =
checkDoubleFloat(lispSleep.multiplyBy(newDoubleFloat(1000))).getValue();
checkDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue();
if (d < 0) type_error(lispSleep, list(Symbol.REAL, Fixnum.ZERO));@@ -1015,6 +1016,17 @@ return (d < Long.MAX_VALUE ? (long) d : Long.MAX_VALUE); }
- public static final int javaSleepNanos(LispObject lispSleep)
- {
double d = // d contains millischeckDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue();
double n = d*1000000; // n contains nanosd = 1.0e6*((long)d); // convert rounded millis to nanosn = n - d; // retain nanos not in millisreturn (n < Integer.MAX_VALUE ? (int) n : Integer.MAX_VALUE);- }
- @DocString(name="sleep", args="seconds", doc="Causes the invoking thread to sleep for SECONDS seconds.\n"+ "SECONDS may be a value between 0 1and 1.")
@@ -1025,7 +1037,8 @@ {
try {
Thread.sleep(javaSleepInterval(arg));
Thread.sleep(javaSleepInterval(arg),- javaSleepNanos(arg)); } catch (InterruptedException e) { currentThread().processThreadInterrupts();
@@ -1208,7 +1221,8 @@
{ try {
object.lockableInstance().wait(javaSleepInterval(timeout));
object.lockableInstance().wait(javaSleepInterval(timeout),javaSleepNanos(timeout)); } catch (InterruptedException e) { currentThread().processThreadInterrupts();On Sat, Feb 1, 2014 at 2:54 PM, James M. Lawrence llmjjmll@gmail.com wrote:
(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.0001))))
For times between 0 and 0.0001 this appears to hang indefinitely. No problem with times above 0.001.
The context is the new timeout option for
bordeaux-threads:condition-wait,
https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp#...
1.3.0-dev-svn-14623 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
Best, lmj
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
On Sat, Feb 1, 2014 at 2:31 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi James,
Thanks for confirming that.
What would you consider the best option when the timeout value becomes too close to 0? I see 2:
- Don't wait.
- Wait at least 1 ns
In the context of bordeaux-threads, I think it would be unexpected if condition-wait did no waiting at all, even if given a timeout that will surely be exceeded. In the limit of the timeout approaching zero, I would say that condition-wait converges to pthread_yield rather than a noop.
On 2/3/14, 19:14, James M. Lawrence wrote: […]
What would you consider the best option when the timeout value becomes too close to 0? I see 2:
- Don't wait.
- Wait at least 1 ns
In the context of bordeaux-threads, I think it would be unexpected if condition-wait did no waiting at all, even if given a timeout that will surely be exceeded. In the limit of the timeout approaching zero, I would say that condition-wait converges to pthread_yield rather than a noop.
[r14362][] fixes CL:SLEEP for intervals less than a millisecond.
For intervals less than or equal to a nanosecond, including an interval of zero, the current thread yields execution to other threads at James' suggestion.
[r14362]: http://abcl.org/trac/changeset/14632
Hi,
The original bug appears to still be there. For example this will hang:
(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.000000001))))
1.4.0-dev-svn-14653 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
--lmj
On Sun, Mar 2, 2014 at 5:08 AM, Mark Evenson evenson@panix.com wrote:
On 2/3/14, 19:14, James M. Lawrence wrote: [...]
What would you consider the best option when the timeout value becomes too close to 0? I see 2:
- Don't wait.
- Wait at least 1 ns
In the context of bordeaux-threads, I think it would be unexpected if condition-wait did no waiting at all, even if given a timeout that will surely be exceeded. In the limit of the timeout approaching zero, I would say that condition-wait converges to pthread_yield rather than a noop.
[r14362][] fixes CL:SLEEP for intervals less than a millisecond.
For intervals less than or equal to a nanosecond, including an interval of zero, the current thread yields execution to other threads at James' suggestion.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 3/20/14, 23:59, James M. Lawrence wrote:
Hi,
The original bug appears to still be there. For example this will hang:
(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.000000001))))
1.4.0-dev-svn-14653 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
Sigh. Yes, this is still not resolved with THREADS:OBJECT-WAIT in abcl-1.4.0-dev, although CL:SLEEP is fixed.
Apparently my thinking on this was incomplete. For the SLEEP, degrading to thread yield make sense for intervals less than a nanosecond. For OBJECT-WAIT is it really the case that you wish to degrade to a thread yield without ever having tried to wait for a notification on the synchronized object?
On Fri, Mar 21, 2014 at 4:04 AM, Mark Evenson evenson@panix.com wrote:
On 3/20/14, 23:59, James M. Lawrence wrote:
Hi,
The original bug appears to still be there. For example this will hang:
(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.000000001))))
1.4.0-dev-svn-14653 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
Sigh. Yes, this is still not resolved with THREADS:OBJECT-WAIT in abcl-1.4.0-dev, although CL:SLEEP is fixed.
Apparently my thinking on this was incomplete. For the SLEEP, degrading to thread yield make sense for intervals less than a nanosecond. For OBJECT-WAIT is it really the case that you wish to degrade to a thread yield without ever having tried to wait for a notification on the synchronized object?
In pthreads, no matter what timeout is given to pthread_cond_timedwait, it will always release and reacquire the mutex. A certain-to-expire timeout just means we are operating within the Planck time of the system.
Because pthread_cond_timedwait can return spuriously, the information it provides is not particularly useful on its own. We must always check to see if "something happened", for instance whether data produced by another thread has arrived. It may have arrived even if pthread_cond_timedwait returned ETIMEDOUT.
From what I understand of java.lang.Object.wait, the model is similar.
The main difference seems to be the weirdo interpretation of 0 = infinity. It's discontinuous: passing 0.00000001 yields a totally different animal than passing 0. I should be able to wait one system Planck time unit (i.e. wait 0, without 0 meaning infinity), but I can't.
I need to add a workaround to the ABCL implementation of bordeaux-threads:condition-wait. If the user passes a timeout of zero then the this should translate to TIMED-WAIT of LEAST-POSITIVE-SINGLE-FLOAT.
On your end, I think you just need to avoid rounding a non-zero value to zero. If the reader rounds a literal to zero then there's nothing you can do, but 0.000000001 is well before that problem. The separation of the reader phase in Lisp does not mix well with the extreme discontinuity between 0 and non-zero values with TIMED-WAIT.
Best, lmj
On Mar 24, 2014, at 19:55, James M. Lawrence llmjjmll@gmail.com wrote:
[…]
On your end, I think you just need to avoid rounding a non-zero value to zero. If the reader rounds a literal to zero then there's nothing you can do, but 0.000000001 is well before that problem. The separation of the reader phase in Lisp does not mix well with the extreme discontinuity between 0 and non-zero values with TIMED-WAIT.
I am very much in agreement that the discontinuity is not a very good API choice on the JVM’s part.
The problem lies in the fact JVM interfaces to thread sleeping [and waiting][1] specify timeouts as integers, so I *have* to do some interpolation for non-zero user values of intervals less than a nanosecond (the “Planck unit” for JVM times).
[1]: http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#wait-long-int...
So, in order to implement
I need to add a workaround to the ABCL implementation of bordeaux-threads:condition-wait. If the user passes a timeout of zero then the this should translate to TIMED-WAIT of LEAST-POSITIVE-SINGLE-FLOAT.
I propose to interpolate non-zero values specified by the user of less than a nanosecond to CL:SLEEP/THREADS:OBJECT-WAIT to mean a sleep/wait for a nanosecond. If the user specifies a zero-value, then she will get an infinite timeout.
P.S. not sure what you mean by the “separation of the reader phase in Lisp does not mix well…”. What does the Lisp reader have to do with the discontinuity of the API?
Thanks for the feedback: we’ll get this fixed to your satisfaction (modulo the “brokenness” of the JVM) for abcl-1.3.1!
On Tue, Mar 25, 2014 at 5:26 AM, Mark Evenson evenson@panix.com wrote:
I propose to interpolate non-zero values specified by the user of less than a nanosecond to CL:SLEEP/THREADS:OBJECT-WAIT to mean a sleep/wait for a nanosecond. If the user specifies a zero-value, then she will get an infinite timeout.
Yes, if we can't sleep/wait for zero seconds, then 1 ns is the next best thing. The misdesign of the java.lang.Object.wait API goes from ugly to wrong for arbitrarily fast machines of the future, but we aren't there yet.
P.S. not sure what you mean by the "separation of the reader phase in Lisp does not mix well...". What does the Lisp reader have to do with the discontinuity of the API?
In retrospect it isn't a significant point. The catastrophic difference in behavior between zero and near-zero is bad enough on its own, but it's made a little bit worse when the reader rounds to zero. Wherever parse trees are used instead of program text (e.g. sending Lisp sexp data to a server), the intended meaning of the code is that much farther away.
On 29 Mar 2014, at 19:41, James M. Lawrence llmjjmll@gmail.com wrote:
On Tue, Mar 25, 2014 at 5:26 AM, Mark Evenson evenson@panix.com wrote:
I propose to interpolate non-zero values specified by the user of less than a nanosecond to CL:SLEEP/THREADS:OBJECT-WAIT to mean a sleep/wait for a nanosecond. If the user specifies a zero-value, then she will get an infinite timeout.
[…]
Please check that the [referenced commit][1] to appear in the soon-to-be released abcl-1.3.1 addresses your needs.
Sincerely, Mark
[1]: http://abcl.org/trac/changeset/14679
Hi, lparallel tests now pass with the timeout change in this pull request
https://github.com/sionescu/bordeaux-threads/pull/6
One thing that puzzles me -- I checked old versions of ABCL back to 1.0.0, and none gave an indefinite wait for (sleep 0). Do you remember why you changed (sleep 0) to (sleep 0.01) in thread-yield in February 2011? I changed it back to (sleep 0) in the pull request, but I didn't realize I was undoing your change until this moment.
Best, lmj
On Thu, Apr 17, 2014 at 7:41 AM, Mark Evenson evenson@panix.com wrote:
On 29 Mar 2014, at 19:41, James M. Lawrence llmjjmll@gmail.com wrote:
On Tue, Mar 25, 2014 at 5:26 AM, Mark Evenson evenson@panix.com wrote:
I propose to interpolate non-zero values specified by the user of less than a nanosecond to CL:SLEEP/THREADS:OBJECT-WAIT to mean a sleep/wait for a nanosecond. If the user specifies a zero-value, then she will get an infinite timeout.
[…]
Please check that the [referenced commit][1] to appear in the soon-to-be released abcl-1.3.1 addresses your needs.
Sincerely, Mark
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 19/04/14 18:44, James M. Lawrence wrote:
Hi, lparallel tests now pass with the timeout change in this pull request
https://github.com/sionescu/bordeaux-threads/pull/6
One thing that puzzles me -- I checked old versions of ABCL back to 1.0.0, and none gave an indefinite wait for (sleep 0). Do you remember why you changed (sleep 0) to (sleep 0.01) in thread-yield in February 2011? I changed it back to (sleep 0) in the pull request, but I didn't realize I was undoing your change until this moment.
As far as I understand it, it is a change in the underlying JVM.
Blame SUNW^H^H^H^HORCL.
On Sat, Apr 19, 2014 at 1:40 PM, Mark Evenson evenson@panix.com wrote:
One thing that puzzles me -- I checked old versions of ABCL back to 1.0.0, and none gave an indefinite wait for (sleep 0). Do you remember why you changed (sleep 0) to (sleep 0.01) in thread-yield in February 2011? I changed it back to (sleep 0) in the pull request, but I didn't realize I was undoing your change until this moment.
As far as I understand it, it is a change in the underlying JVM.
Blame SUNW^H^H^H^HORCL.
bt:thread-yield is going to have rare use on implementations with pre-emptive threads such as ABCL, and it's difficult to contrive a case where it matters. I would have left it at (sleep 0) except that I don't know why the 2011 change was made. What was the JVM change and is it relevant now?
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Sat, Apr 19, 2014 at 1:40 PM, Mark Evenson evenson@panix.com wrote:
On 19/04/14 18:44, James M. Lawrence wrote:
Hi, lparallel tests now pass with the timeout change in this pull request
https://github.com/sionescu/bordeaux-threads/pull/6
One thing that puzzles me -- I checked old versions of ABCL back to 1.0.0, and none gave an indefinite wait for (sleep 0). Do you remember why you changed (sleep 0) to (sleep 0.01) in thread-yield in February 2011? I changed it back to (sleep 0) in the pull request, but I didn't realize I was undoing your change until this moment.
As far as I understand it, it is a change in the underlying JVM.
Blame SUNW^H^H^H^HORCL.
What should bt:thread-yield do? (sleep 0) or (sleep 0.01) or (sleep least-positive-single-float) or something else?
_______________________________________________ Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 19 Apr 2014, at 19:53, James M. Lawrence llmjjmll@gmail.com wrote:
[…]
What should bt:thread-yield do? (sleep 0) or (sleep 0.01) or (sleep least-positive-single-float) or something else?
ABCL should implement a THREADS:YIELD primitive mapping directly to java.lang.Thread.yield().
In the intermin, impelement bt:thread-yield as
(java:jcall "yield" (java:jstatic "currentThread" "java.lang.Thread”))
Hi Mark,
Are you sure? According to this article: http://stackoverflow.com/questions/15048170/difference-between-thread-yield-..., there's no stable Yield implementation across platforms on Java. Do we really want to provide platform defined behaviour?
Bye,
Erik.
On Tue, Apr 22, 2014 at 12:50 PM, Mark Evenson evenson@panix.com wrote:
On 19 Apr 2014, at 19:53, James M. Lawrence llmjjmll@gmail.com wrote:
[…]
What should bt:thread-yield do? (sleep 0) or (sleep 0.01) or (sleep least-positive-single-float) or something else?
ABCL should implement a THREADS:YIELD primitive mapping directly to java.lang.Thread.yield().
In the intermin, impelement bt:thread-yield as
(java:jcall "yield" (java:jstatic "currentThread""java.lang.Thread”))
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On 22 Apr 2014, at 15:19, Erik Huelsmann ehuels@gmail.com wrote:
Hi Mark,
Are you sure? According to this article: http://stackoverflow.com/questions/15048170/difference-between-thread-yield-... , there's no stable Yield implementation across platforms on Java. Do we really want to provide platform defined behaviour?
[The Java 7 documentation of java.lang.Thread.yield() says that its use provides][1]
"A hint to the scheduler that the current thread is willing to yield its current use of a processor. The scheduler is free to ignore this hint. Yield is a heuristic attempt to improve relative progression between threads that would otherwise over-utilise a CPU. Its use should be combined with detailed profiling and benchmarking to ensure that it actually has the desired effect."
[1]: http://docs.oracle.com/javase/7/docs/api/java/lang/Thread.html#yield%28%29
This clearly denotes that the semantics of a call to yield() constitute a hint to the scheduler, not an explicit contract. Java the language is “platform dependent” behavior on the underlying JVM for many things, of which how yield() precisely interacts with the scheduler is but one detail. We don’t refuse to allow access to underlying java.lang.Thread functions dependent on whether the underlying JVM has green threads, or M:N mapping models to hardware threads like some previous versions of Solaris had, now do we?
We already provide access to "platform defined behavior” all over in many unexamined way: that is part of working on the JVM. I don’t really see how [r14690][] is that different, but I am certainly willing to listen to reason.
[r14690]: http://abcl.org/trac/changeset/14690
Seems like sleep(0) and yield() are implementation-specific enough that they can actually mean the same thing: http://stackoverflow.com/a/17494898/296025
On Tue, Apr 22, 2014 at 3:19 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Mark,
Are you sure? According to this article: http://stackoverflow.com/questions/15048170/difference-between-thread-yield-..., there's no stable Yield implementation across platforms on Java. Do we really want to provide platform defined behaviour?
Bye,
Erik.
On Tue, Apr 22, 2014 at 12:50 PM, Mark Evenson evenson@panix.com wrote:
On 19 Apr 2014, at 19:53, James M. Lawrence llmjjmll@gmail.com wrote:
[…]
What should bt:thread-yield do? (sleep 0) or (sleep 0.01) or (sleep least-positive-single-float) or something else?
ABCL should implement a THREADS:YIELD primitive mapping directly to java.lang.Thread.yield().
In the intermin, impelement bt:thread-yield as
(java:jcall "yield" (java:jstatic "currentThread""java.lang.Thread”))
-- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
-- Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
Armedbear-devel mailing list Armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Confirmed that the java.lang.Object.wait(int, int) interface exists in [java5][].
[java5]: http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html
On Feb 1, 2014, at 17:36, Erik Huelsmann ehuels@gmail.com wrote:
Index: LispThread.java
--- LispThread.java (revision 14464) +++ LispThread.java (working copy) @@ -1004,11 +1004,12 @@ };
- private static DoubleFloat factor1000 = new DoubleFloat(1000);
- public static final long javaSleepInterval(LispObject lispSleep)
- { double d =
checkDoubleFloat(lispSleep.multiplyBy(new DoubleFloat(1000))).getValue();
checkDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue(); if (d < 0) type_error(lispSleep, list(Symbol.REAL, Fixnum.ZERO));@@ -1015,6 +1016,17 @@ return (d < Long.MAX_VALUE ? (long) d : Long.MAX_VALUE); }
- public static final int javaSleepNanos(LispObject lispSleep)
- {
double d = // d contains millischeckDoubleFloat(lispSleep.multiplyBy(factor1000)).getValue();double n = d*1000000; // n contains nanosd = 1.0e6*((long)d); // convert rounded millis to nanosn = n - d; // retain nanos not in millisreturn (n < Integer.MAX_VALUE ? (int) n : Integer.MAX_VALUE);- }
- @DocString(name="sleep", args="seconds", doc="Causes the invoking thread to sleep for SECONDS seconds.\n"+ "SECONDS may be a value between 0 1and 1.")
@@ -1025,7 +1037,8 @@ {
try {
Thread.sleep(javaSleepInterval(arg));
Thread.sleep(javaSleepInterval(arg),javaSleepNanos(arg)); } catch (InterruptedException e) { currentThread().processThreadInterrupts();@@ -1208,7 +1221,8 @@
{ try {
object.lockableInstance().wait(javaSleepInterval(timeout));
object.lockableInstance().wait(javaSleepInterval(timeout),javaSleepNanos(timeout)); } catch (InterruptedException e) { currentThread().processThreadInterrupts();
On Feb 1, 2014, at 17:50, Mark Evenson evenson@panix.com wrote:
Confirmed that the java.lang.Object.wait(int, int) interface exists in [java5][]. java.lang.Object.wait(int, int)
err: java.lang.Object.wait(long, int)
On Feb 1, 2014, at 14:54, James M. Lawrence llmjjmll@gmail.com wrote:
(defun test () (let ((object (cons nil nil))) (threads:synchronized-on object (threads:object-wait object 0.0001))))
For times between 0 and 0.0001 this appears to hang indefinitely. No problem with times above 0.001.
The context is the new timeout option for bordeaux-threads:condition-wait,
https://github.com/sionescu/bordeaux-threads/blob/master/src/impl-abcl.lisp#...
1.3.0-dev-svn-14623 Java_HotSpot(TM)_Server_VM-Oracle_Corporation-1.7.0_04-b20 i386-Linux-3.2.0-24-generic-pae
Filed as [ticket-345][]. We need to possibly use the sub-millisecond timeouts afforded by the NIO interfaces, which may not be present all the way back to Java 5.
[ticket-345]: http://abcl.org/trac/ticket/345
armedbear-devel@common-lisp.net
-
Alessio Stalla -
Erik Huelsmann -
James M. Lawrence -
Mark Evenson