[Openmcl-devel] Semaphore troubles

[Erik Pearson]

Hi James,

I'm sure Gary et al. will have a fix soon -- today if past performance is
any measure -- but for now try this. In your ccl directory (/opt/ccl/ccl in
my system, because I install my ccl from svn in /opt/ccl), in the level-1
directory, in the file l1-lisp-threads.lisp,  hunt down and replace the
%nanosleep function with this:

#-windows-target
(defun %nanosleep (seconds nanoseconds)
  (with-process-whostate ("Sleep")
    (rlet ((a :timespec)
           (b :timespec))
  (setf (pref a :timespec.tv_sec) seconds
(pref a :timespec.tv_nsec) nanoseconds)
  (let ((aptr a)
(bptr b))
    (loop
       (let ((result
      (external-call #+darwin-target "_nanosleep"
     #-darwin-target "nanosleep"
     :address aptr
     :address bptr
     :signed-fullword)))
 (declare (type (signed-byte 32) result))
 (if (and (< result 0)
  (eql (%get-errno) (- #$EINTR)))
     (psetq aptr bptr bptr aptr)
     (return))))))))

All I did was remove the OS X workaround code. I'm working with the
up-to-date trunk, v 1.9.

I'm sure the official fix will be in soon, and will probably conditionalize
the OS X (Leopard) code.

Then fire up ccl and issue (rebuild-ccl). I've had the 1 second test
running all night, with no issues at all, and the 0.01 with just two, at
800,482 and 2,236,556 iterations.

It is notable that sleep does not guarantee a high degree of accuracy in
the sleep time -- to wit, if it is the underlying call to nanosleep is
interrupted and then continued (as the lisp code above does) the sleep
duration will drift upwards (increased by the time between the interruption
and the next call to nanosleep.)

There is a another Linux/Posix call "clock_nanosleep" which can be used to
set an absolute time for the sleep, which avoids the drift issue. Perhaps
worth pursuing?


Erik.


On Thu, May 10, 2012 at 7:39 AM, James M. Lawrence <llmjjmll at gmail.com>wrote:

> On Thu, May 10, 2012 at 2:10 AM, Gary Byers <gb at clozure.com> wrote:
> >> The upshot of what you're saying is that Clozure cannot reliably
> >> distribute work across threads, while other CL implementations can.
> >
> > [...]
> >
> > Second of all, CCL doesn't "distribute work between threads"; neither
> > does SBCL, nor do recent versions of LispWorks, nor do other lisp
> > implementations that offer native threads.
>
> I was simply referring to the ability to reliably send tasks to a
> worker thread pool and receive a notification for each task
> immediately after it completes. This is exactly the use case I have,
> and it is exactly what the test case asserts.
>
> I should mention my machine may be unusual -- it's a Core-i7 but with
> 32-bit Linux installed. (Ubuntu 11 repeatedly failed to install,
> Ubuntu 12 was not released yet, and when I grabbed the nightly build
> at 2AM it was the 32-bit one. I plan to install 64-bit, but not yet.)
>
> I just ran the test again: 2 second sleep failed at 37 iterations; 10
> second sleep failed at 86. Rarely it goes past 100 -- if it does, I
> restart CCL to jostle things up, but that may only be superstition (on
> SBCL I once had a condition variable problem which was either fully
> present or fully absent depending upon a dice roll at launch).
>
> I will grant ssh access to my machine.
>
> ccl-1.8/lx86cl, md5 040409ba578edfa8b3dd62b009d57929
>
> 3.2.0-24-generic-pae #37-Ubuntu SMP Wed Apr 25 10:47:59 UTC 2012 i686
> i686 i386 GNU/Linux
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20120510/537db497/attachment.htm>