From: Rick T. <ta...@ui...> - 2006-01-04 17:44:12
|
i hope this isn't too naive a question but...in sbcl's native thread support, is there any way to do a pthread_cond_timedwait ? Im trying to rewrite a music scheduler so that it "blocks" if its queue has no notes, "sleeps" in between notes, but can be woken up from sleep if a note actually arrives in the queue during the sleep (a "nap" i guess :)) I see that Thread A can use a waitqueue and do pthread_cond_wait until THread B notifies the queue that there is someting in it. I also see that Thread B can sleep for a specific amount of time, but i want A be able to terminate B's sleep if -- in fact -- something becomes available while B is sleeping. is this latter feature somehow built into condition-notify?? if not i dont understand how to do this. Also is there any ability to set the priority of a thread? id like to set a high priority because any small stutter during music playback is audible. --rick |
From: Rick T. <ta...@ui...> - 2006-01-04 17:52:46
|
arrrg! sorry, i see i got my A's and B's crossed! it should read: > I see that Thread A can use a waitqueue and do pthread_cond_wait > until THread B notifies the queue that there is someting in it. I > also see that Thread A can sleep for a specific amount of time, but > i want B be able to terminate A's sleep if -- in fact -- something > becomes available while A is sleeping. is this latter feature > somehow built into condition-notify?? if not i dont understand how > to do this. > > Also is there any ability to set the priority of a thread? id like > to set a high priority because any small stutter during music > playback is audible. > > --rick |
From: <me...@ho...> - 2006-01-05 09:06:11
|
On Wednesday 04 January 2006 19:00, Rick Taube wrote: > arrrg! sorry, i see i got my A's and B's crossed! it should read: > > I see that Thread A can use a waitqueue and do pthread_cond_wait > > until THread B notifies the queue that there is someting in it. I > > also see that Thread A can sleep for a specific amount of time, but > > i want B be able to terminate A's sleep if -- in fact -- something > > becomes available while A is sleeping. is this latter feature > > somehow built into condition-notify?? if not i dont understand how > > to do this. Maybe I don't quite understand the question, but there is a=20 reader/writer example in the user manual to show how it's done. > > > > Also is there any ability to set the priority of a thread? id like > > to set a high priority because any small stutter during music > > playback is audible. Not officially. You may call pthread_{s,g}etschedparam via alien. You'll=20 need the pthread_t id for the thread: (sb-thread::thread-os-thread sb-thread:*current-thread*) Cheers, G=E1bor > > > > --rick > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files for problems? Stop! Download the new AJAX search engine > that makes searching your log files as easy as surfing the web.=20 > DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Rick T. <ta...@ui...> - 2006-01-05 14:41:55
|
> Maybe I don't quite understand the question, but there is a > reader/writer example in the user manual to show how it's done. hi thanks for the response. yes, that example is what prompted me to write my question: Like the Reader, the scheduler i have can use a waitqueue to block if its queue is empty. however, if the queue contains entries then my scheduler starts playing notes: while it plays it checks the current time (gettimeofday) against the timestamp of the next event in the queue and sleeps until that time is current, then it pops the note, sends it out, and so on untile the queue is empty. meanwhile the writer thread can alwasy add more notes into the reader's queue. so they are similar But here is what i dont understand: if the reader is currently "sleeping" until the next note AND the Writer thread adds another note that has to be played _right away_ then the reader has to "wake up". and that is what pthreads_cond_timedwait would let me do, ie the reader would use it to "sleep until the next note" so the writer could wake it up early if it needs to. but I dont see how to do this with the sbcl api. would be be possbile to provide that feature by redefining condition-wait to take an optional 'timeout' time? (condition-wait *buffer-queue* *buffer-lock* [timeout]) > Not officially. You may call pthread_{s,g}etschedparam via alien. > You'll > need the pthread_t id for the thread: ok thats good to know, ill see if i can tweek priority that way my making which brings up this: we actually have this scheduler working (openmcl) via a CFFI interface to posix threads package and just makeing posix lib calls directly to make/maniuplte our threads. it works great in openmcl but it doesnt seem to run in sbcl, i guess bevause calling pthread library directly interferes with sbcls own notion of threads ??? its too bad because at some level its all pthreads i think: ; rts running! *** glibc detected *** malloc(): memory corruption: 0x0827be70 *** fatal error encountered in SBCL pid 25030(tid 3086920000): %PRIMITIVE HALT called; the party is over. The system is too badly corrupted or confused to continue at the Lisp level. If the system had been compiled with the SB-LDB feature, we'd drop into the LDB low-level debugger now. But there's no LDB in this build, so we can't really do anything but just exit, sorry. Process inferior-lisp exited abnormally with code 1 so im stuck: i cant seems to launch pthreads from the lib directly and i cant see how to use the existing thread api to to this, which is why im asking for advice or pointers on how to proceed. |
From: <me...@ho...> - 2006-01-05 21:07:46
|
On Thursday 05 January 2006 15:41, Rick Taube wrote: > (condition-wait *buffer-queue* *buffer-lock* [timeout]) Please test this: Index: src/code/target-thread.lisp =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v retrieving revision 1.55 diff -u -p -r1.55 target-thread.lisp =2D-- src/code/target-thread.lisp 18 Nov 2005 12:28:40 -0000 1.55 +++ src/code/target-thread.lisp 5 Jan 2006 20:12:17 -0000 @@ -237,7 +237,7 @@ this mutex." (+ (sb!kernel:get-lisp-obj-address waitqueue) (- (* 3 sb!vm:n-word-bytes) sb!vm:instance-pointer-lowtag)))) =20 =2D(defun condition-wait (queue mutex) +(defun condition-wait (queue mutex &key timeout) #!+sb-doc "Atomically release MUTEX and enqueue ourselves on QUEUE. Another thread may subsequently notify us using CONDITION-NOTIFY, at which @@ -258,9 +258,12 @@ time we reacquire MUTEX and return to th ;; this comment, it will change queue->data, and so ;; futex-wait returns immediately instead of sleeping. ;; Ergo, no lost wakeup =2D (with-pinned-objects (queue me) =2D (futex-wait (waitqueue-data-address queue) =2D (sb!kernel:get-lisp-obj-address me)))) + (handler-case + (sb-ext:with-timeout timeout + (with-pinned-objects (queue me) + (futex-wait (waitqueue-data-address queue) + (sb!kernel:get-lisp-obj-address me)))) + (sb-ext:timeout () nil))) ;; If we are interrupted while waiting, we should do these things ;; before returning. Ideally, in the case of an unhandled signal, ;; we should do them before entering the debugger, but this is You could do almost the same by wrapping the condition-wait in a with-timeout, but that's unsafe since it might interrupt the unwind-protect cleanup form. > > > Not officially. You may call pthread_{s,g}etschedparam via alien. > > You'll need the pthread_t id for the thread: > > ok thats good to know, ill see if i can tweek priority that way my > making [...] > so im stuck: i cant seems to launch pthreads from the lib directly > and i cant see how to use the existing thread api to to this, which > is why im asking for advice or pointers on how to proceed. If you are calling lisp from a pthread that was not created by MAKE-THREAD, well that's going to lose, no way around it. If you are not then I need more info, preferrably a small test program. Cheers, G=E1bor |
From: Aleksandar B. <a_...@ya...> - 2006-01-22 14:40:20
|
Hi, Just a minor fix to Gabor's patch: &key timeout => &key (timeout 0) Alex PS. I tried the patch and it seems to work. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Aleksandar B. <a_...@ya...> - 2006-01-22 15:01:27
|
> PS. I tried the patch and it seems to work. Hm, it works when you apply the fix at run time. When I tried to rebuild SBCL with the patch, I got: ... obj/from-xc/src/code/target-thread.lisp-obj failed AVER: (PACKAGE-OK-FOR-TARGET-SYMBOL-P RESULT) ... Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Rick T. <ta...@ui...> - 2006-01-22 15:08:03
|
Yes this is also the case for me -- I was not been able to apply the patch and then build the system from sources ether (red hat/planet ccrma). then start of semester has kept me from looking into it further last week. --Rick Taube On Jan 22, 2006, at 9:01 AM, Aleksandar Bakic wrote: >> PS. I tried the patch and it seems to work. > > Hm, it works when you apply the fix at run time. When I tried to > rebuild SBCL > with the patch, I got: > > ... > obj/from-xc/src/code/target-thread.lisp-obj > failed AVER: > (PACKAGE-OK-FOR-TARGET-SYMBOL-P RESULT) > ... > > Alex > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel |
From: Christophe R. <cs...@ca...> - 2006-01-22 15:47:36
|
Rick Taube <ta...@ui...> writes: > Yes this is also the case for me -- I was not been able to apply the > patch and then build the system from sources ether (red hat/planet > ccrma). then start of semester has kept me from looking into it > further last week. Some of the patch needs to have "sb-ext" replaced by "sb!ext". Then it should build from source. Cheers, Christophe |
From: Aleksandar B. <a_...@ya...> - 2006-01-22 15:50:03
|
OK, I tried harder :) It seems that sb-ext should be replaced by sb!ext. It builds, at least. I'll let you know if there are any problems. Alex --- Rick Taube <ta...@ui...> wrote: > Yes this is also the case for me -- I was not been able to apply the > patch and then build the system from sources ether (red hat/planet > ccrma). then start of semester has kept me from looking into it further > last week. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Aleksandar B. <a_...@ya...> - 2006-01-23 13:41:39
|
Hi, Here is the patch that seems to work: Index: target-thread.lisp =================================================================== RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v retrieving revision 1.55 diff -u -r1.55 target-thread.lisp --- target-thread.lisp 18 Nov 2005 12:28:40 -0000 1.55 +++ target-thread.lisp 23 Jan 2006 13:39:47 -0000 @@ -237,7 +237,7 @@ (+ (sb!kernel:get-lisp-obj-address waitqueue) (- (* 3 sb!vm:n-word-bytes) sb!vm:instance-pointer-lowtag)))) -(defun condition-wait (queue mutex) +(defun condition-wait (queue mutex &key (timeout 0)) #!+sb-doc "Atomically release MUTEX and enqueue ourselves on QUEUE. Another thread may subsequently notify us using CONDITION-NOTIFY, at which @@ -258,9 +258,12 @@ ;; this comment, it will change queue->data, and so ;; futex-wait returns immediately instead of sleeping. ;; Ergo, no lost wakeup - (with-pinned-objects (queue me) - (futex-wait (waitqueue-data-address queue) - (sb!kernel:get-lisp-obj-address me)))) + (handler-case + (sb!ext:with-timeout timeout + (with-pinned-objects (queue me) + (futex-wait (waitqueue-data-address queue) + (sb!kernel:get-lisp-obj-address me)))) + (sb!ext:timeout () nil))) ;; If we are interrupted while waiting, we should do these things ;; before returning. Ideally, in the case of an unhandled signal, ;; we should do them before entering the debugger, but this is Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Aleksandar B. <a_...@ya...> - 2006-03-22 19:41:28
|
Hi, I have noticed some sb-ext:timeout signals not caught in an application, and I believe that condition-wait is their only possible source in the application. I'll experiment some more with the package names (e.g., try sb-ext:timeout instead of sb!ext:timeout). Alex --- Aleksandar Bakic <a_...@ya...> wrote: > Hi, > > Here is the patch that seems to work: > > Index: target-thread.lisp > =================================================================== > RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v > retrieving revision 1.55 > diff -u -r1.55 target-thread.lisp > --- target-thread.lisp 18 Nov 2005 12:28:40 -0000 1.55 > +++ target-thread.lisp 23 Jan 2006 13:39:47 -0000 > @@ -237,7 +237,7 @@ > (+ (sb!kernel:get-lisp-obj-address waitqueue) > (- (* 3 sb!vm:n-word-bytes) sb!vm:instance-pointer-lowtag)))) > > -(defun condition-wait (queue mutex) > +(defun condition-wait (queue mutex &key (timeout 0)) > #!+sb-doc > "Atomically release MUTEX and enqueue ourselves on QUEUE. Another > thread may subsequently notify us using CONDITION-NOTIFY, at which > @@ -258,9 +258,12 @@ > ;; this comment, it will change queue->data, and so > ;; futex-wait returns immediately instead of sleeping. > ;; Ergo, no lost wakeup > - (with-pinned-objects (queue me) > - (futex-wait (waitqueue-data-address queue) > - (sb!kernel:get-lisp-obj-address me)))) > + (handler-case > + (sb!ext:with-timeout timeout > + (with-pinned-objects (queue me) > + (futex-wait (waitqueue-data-address queue) > + (sb!kernel:get-lisp-obj-address me)))) > + (sb!ext:timeout () nil))) > ;; If we are interrupted while waiting, we should do these things > ;; before returning. Ideally, in the case of an unhandled signal, > ;; we should do them before entering the debugger, but this is > > > Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Aleksandar B. <a_...@ya...> - 2006-03-25 15:27:27
|
Hi, > I'll experiment some more with the package names (e.g., try sb-ext:timeout > instead of sb!ext:timeout). Changing the package of the timeout symbol does not work, but I managed to compile with the following change: - (sb!ext:timeout () nil))) + (sb!ext:timeout (c) (declare (ignore c)) nil))) Will see if this fixes the problem. (Sorry if someone has already fixed it and I haven't noticed.) Alex __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Nikodemus S. <nik...@ra...> - 2006-05-26 07:30:51
|
Aleksandar Bakic <a_...@ya...> writes: Scanning through the list, this seems to have fallen by the wayside. Any objections to merging this once we're out of freeze? > Index: target-thread.lisp > =================================================================== > RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v > retrieving revision 1.55 > diff -u -r1.55 target-thread.lisp > --- target-thread.lisp 18 Nov 2005 12:28:40 -0000 1.55 > +++ target-thread.lisp 23 Jan 2006 13:39:47 -0000 > @@ -237,7 +237,7 @@ > (+ (sb!kernel:get-lisp-obj-address waitqueue) > (- (* 3 sb!vm:n-word-bytes) sb!vm:instance-pointer-lowtag)))) > > -(defun condition-wait (queue mutex) > +(defun condition-wait (queue mutex &key (timeout 0)) > #!+sb-doc > "Atomically release MUTEX and enqueue ourselves on QUEUE. Another > thread may subsequently notify us using CONDITION-NOTIFY, at which > @@ -258,9 +258,12 @@ > ;; this comment, it will change queue->data, and so > ;; futex-wait returns immediately instead of sleeping. > ;; Ergo, no lost wakeup > - (with-pinned-objects (queue me) > - (futex-wait (waitqueue-data-address queue) > - (sb!kernel:get-lisp-obj-address me)))) > + (handler-case > + (sb!ext:with-timeout timeout > + (with-pinned-objects (queue me) > + (futex-wait (waitqueue-data-address queue) > + (sb!kernel:get-lisp-obj-address me)))) > + (sb!ext:timeout () nil))) > ;; If we are interrupted while waiting, we should do these things > ;; before returning. Ideally, in the case of an unhandled signal, > ;; we should do them before entering the debugger, but this is Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: <me...@ho...> - 2006-05-26 07:57:43
|
On Friday 26 May 2006 09:30, Nikodemus Siivola wrote: > Aleksandar Bakic <a_...@ya...> writes: > > Scanning through the list, this seems to have fallen by the wayside. > Any objections to merging this once we're out of freeze? Well, for one thing it lacks documentation on what TIMEOUT means. I'd prefer to see NIL as the default value of TIMEOUT (probably WITH-TIMEOUT needs to be able to handle that too) instead of the misleading 0 which to me implies "try to get the lock and return immediately even if it is not available". Plus WITH-TIMEOUT is currently broken with regards to nesting. Obviously, this only applies if this is called within another WITH-TIMEOUT. Oh, and there is a race so that the client cannot tell from the (undocumented) return value if the operation was successful or not. Futexes support timeouts, maybe using that would have better performance and may solve the race too. What about lutexes? Cheers, Gabor > > > Index: target-thread.lisp > > =================================================================== > > RCS file: /cvsroot/sbcl/sbcl/src/code/target-thread.lisp,v > > retrieving revision 1.55 > > diff -u -r1.55 target-thread.lisp > > --- target-thread.lisp 18 Nov 2005 12:28:40 -0000 1.55 > > +++ target-thread.lisp 23 Jan 2006 13:39:47 -0000 > > @@ -237,7 +237,7 @@ > > (+ (sb!kernel:get-lisp-obj-address waitqueue) > > (- (* 3 sb!vm:n-word-bytes) > > sb!vm:instance-pointer-lowtag)))) > > > > -(defun condition-wait (queue mutex) > > +(defun condition-wait (queue mutex &key (timeout 0)) > > #!+sb-doc > > "Atomically release MUTEX and enqueue ourselves on QUEUE. > > Another thread may subsequently notify us using CONDITION-NOTIFY, > > at which @@ -258,9 +258,12 @@ > > ;; this comment, it will change queue->data, and so > > ;; futex-wait returns immediately instead of sleeping. > > ;; Ergo, no lost wakeup > > - (with-pinned-objects (queue me) > > - (futex-wait (waitqueue-data-address queue) > > - (sb!kernel:get-lisp-obj-address me)))) > > + (handler-case > > + (sb!ext:with-timeout timeout > > + (with-pinned-objects (queue me) > > + (futex-wait (waitqueue-data-address queue) > > + (sb!kernel:get-lisp-obj-address > > me)))) + (sb!ext:timeout () nil))) > > ;; If we are interrupted while waiting, we should do these > > things ;; before returning. Ideally, in the case of an unhandled > > signal, ;; we should do them before entering the debugger, but this > > is > > Cheers, > > -- Nikodemus Schemer: "Buddha is small, clean, and > serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." |
From: Juho S. <js...@ik...> - 2006-01-22 15:45:33
|
<a_...@ya...> wrote: >> PS. I tried the patch and it seems to work. > > Hm, it works when you apply the fix at run time. When I tried to rebuild SBCL > with the patch, I got: > > ... > obj/from-xc/src/code/target-thread.lisp-obj > failed AVER: > (PACKAGE-OK-FOR-TARGET-SYMBOL-P RESULT) > ... Probably you just need to replace any uses of SB-FOO with SB!FOO in the patch. -- Juho Snellman |