From: Glenn T. <gt...@um...> - 2010-03-04 04:13:09
|
In target-thread.lisp there is the following comment (in get-mutex): ;; FIXME: Lutexes do not currently support deadlines, as at least ;; on Darwin pthread_foo_timedbar functions are not supported: ;; this means that we probably need to use the Carbon multiprocessing ;; functions on Darwin. ;; ;; FIXME: This is definitely not interrupt safe: what happens if ;; we get hit (1) during the lutex calls (ok, they may be safe, ;; but has that been checked?) (2) after the lutex call, but ;; before setting the mutex owner. #!+sb-lutex The bit of code related to this comment is causing a hang in threads.impure.lisp where deadlines are being used. My question is does anyone remember what the particular issue was? On Snow Leopard pthread_cond_timedwait() (which is the only pthread_foo_timedbar function that I could find that seemed related to the comment) seems to be supported. I tried using pthread-futex.c rather than pthread-lutex.c. (disabled sb-lutex, enabled sb-pthread-futex). That seems to work for some of the deadline tests (that were hanging but started passing with that change) but other tests that were passing now hang when I do the switch. Also, pthread-futex.c didn't compile at first - so it doesn't seem like its really being used and makes me wonder if there are other known issues with it that caused it to be deprecated. Any insight greatly appreciated! Thanks, Glenn V. Glenn Tarcea gt...@um... |
From: Tobias C. R. <tc...@fr...> - 2010-03-04 08:37:39
|
Glenn Tarcea <gt...@um...> writes: > The bit of code related to this comment is causing a hang in > threads.impure.lisp where deadlines are being used. Slightly related question: Why doesn't the WITH-TEST macro expand to a WITH-TIMEOUT so instead of hanging, we could just get test failures? (Perhaps it should rather expand to both WITH-TIMEOUT for a hard limit, and WITH-DEADLINE for a soft limit. -T. |
From: Glenn T. <gt...@um...> - 2010-03-04 12:05:33
|
I can try that. I'm still learning what can and can't be done and wasn't aware of this ability. But I'm having fun digging in :-) I'm not so sure I understand all the interactions but I'm going to see if I can put deadline support in when using lutexes. It looks like MacOS is now supporting the pthread_foo_timedbar() functions that the comment was referring to. I'll see what I can do about changing with-test. Thanks, Glenn V. Glenn Tarcea gt...@um... On Mar 4, 2010, at 3:37 AM, Tobias C. Rittweiler wrote: > Glenn Tarcea <gt...@um...> writes: > >> The bit of code related to this comment is causing a hang in >> threads.impure.lisp where deadlines are being used. > > Slightly related question: > > Why doesn't the WITH-TEST macro expand to a WITH-TIMEOUT so instead of > hanging, we could just get test failures? (Perhaps it should rather > expand to both WITH-TIMEOUT for a hard limit, and WITH-DEADLINE for a > soft limit. > > -T. > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > |
From: Nikodemus S. <nik...@ra...> - 2010-03-04 12:57:29
|
On 4 March 2010 14:05, Glenn Tarcea <gt...@um...> wrote: > I can try that. I'm still learning what can and can't be done and wasn't aware of this > ability. But I'm having fun digging in :-) > I'm not so sure I understand all the interactions but I'm going to see if I can put > deadline support in when using lutexes. It looks like MacOS is now supporting the > pthread_foo_timedbar() functions that the comment was referring to. Yep, the comment is out of date. I'm pretty sure there is a patch hanging around somewhere that added support for deadlines on lutex platforms as well. Cheers, -- Nikodemus |
From: Paul K. <pk...@gm...> - 2010-03-04 22:20:56
|
On 2010-03-04, at 7:32 AM, Nikodemus Siivola wrote: > On 4 March 2010 14:05, Glenn Tarcea <gt...@um...> wrote: > >> I can try that. I'm still learning what can and can't be done and wasn't aware of this >> ability. But I'm having fun digging in :-) > >> I'm not so sure I understand all the interactions but I'm going to see if I can put >> deadline support in when using lutexes. It looks like MacOS is now supporting the >> pthread_foo_timedbar() functions that the comment was referring to. > > Yep, the comment is out of date. I'm pretty sure there is a patch > hanging around somewhere that added support for deadlines on lutex > platforms as well. I think the right way to do it is to use mach's interfaces directly. The native synchronisation primitives on OS X are (generalised) semaphores; with some luck, they'll be more robust and performant than the pthread compatibility layer. The semaphores are generalised to easily represent wait queues (by not allowing the count to become positive). In addition to the usual signal (post) and wait/timed_wait, they also support: - semaphore_signal_all (wait queue broadcast) - semaphore_wait_signal (atomically wait on one semaphore and signal another) - semaphore_timedwait_signal - semaphore_signal_thread (signal a single thread without increasing the semaphore's count) These translate directly into syscalls, so we can hope they won't break as easily as pthread's stuff. Even better: they're represented as unsigned ints (mach port ids) in the userland! We could also use the thread control API to stop the world instead of using unix signals (thread_suspend) [pseudo-atomic isn't hard to get right]. Paul Khuong |
From: V. G. T. <gt...@um...> - 2010-03-04 15:51:19
|
> > Yep, the comment is out of date. I'm pretty sure there is a patch > hanging around somewhere that added support for deadlines on lutex > platforms as well. > Ah good, then hopefully that means I don't need to worry about backwards compatibility. If you dig up this patch let me know. I'll look around and see what I can find, and if not then I'll see how badly I can break things by trying to do it myself. :-) I think I'll try extending with-test first so I can get through all tests even if they end up failing due to timeout. That will hopefully give me a sense how close things are on the Mac port to passing all the tests. Thanks, Glenn V. Glenn Tarcea gt...@um... |
From: David L. R. <ra...@cs...> - 2010-03-04 16:16:45
|
Hi Glenn, Back in December and January, I wrote a patch (with the help of Nikodemus and others) that added timeout support for futexes on what I think was all of SBCL's multi-threading platforms/options. I've had some trouble linking sourceforge email archives in the past, so I'm making pdfs and hosting them on my corner of the web. Here's the diff between the repository at the time and my changed repository: http://www.cs.utexas.edu/users/ragerdl/git-diff.txt And here's the discussion thread. The part about which you care starts on page 18 of the pdf: http://userweb.cs.utexas.edu/users/ragerdl/timed-waiting-discussion.pdf The patch does not account for the latest changes to the futex library. I'd be happy to update the patch if someone wouldn't mind reviewing and submitting it. Thanks, David On Thu, Mar 4, 2010 at 9:50 AM, V. Glenn Tarcea <gt...@um...> wrote: >> >> Yep, the comment is out of date. I'm pretty sure there is a patch >> hanging around somewhere that added support for deadlines on lutex >> platforms as well. |
From: V. G. T. <gt...@um...> - 2010-03-04 19:09:01
|
Hi David, Thanks! If you update the patch and send it to me I will test it against MacOSX. I don't have access to many of the other platforms to test against though. If you don't have time to update the patch I'll give it a try based on the links below and anything else you can send. Does this mean that the (L)utex code goes away? On the Mac it is currently using (L)utexes as opposed to (F)utexes. Thanks, Glenn V. Glenn Tarcea gt...@um... > -----Original Message----- > From: ra...@gm... [mailto:ra...@gm...] On Behalf Of David L. > Rager > Sent: Thursday, March 04, 2010 11:17 AM > To: V. Glenn Tarcea > Cc: sbc...@li... > Subject: Re: [Sbcl-devel] Question on Futex Comment (Another MacOSX > related item) > > Hi Glenn, > > Back in December and January, I wrote a patch (with the help of > Nikodemus and others) that added timeout support for futexes on what I > think was all of SBCL's multi-threading platforms/options. I've had > some trouble linking sourceforge email archives in the past, so I'm > making pdfs and hosting them on my corner of the web. > > > Here's the diff between the repository at the time and my changed > repository: > > http://www.cs.utexas.edu/users/ragerdl/git-diff.txt > > > And here's the discussion thread. The part about which you care > starts on page 18 of the pdf: > > http://userweb.cs.utexas.edu/users/ragerdl/timed-waiting-discussion.pdf > > > The patch does not account for the latest changes to the futex > library. I'd be happy to update the patch if someone wouldn't mind > reviewing and submitting it. > > Thanks, > David > > > > > On Thu, Mar 4, 2010 at 9:50 AM, V. Glenn Tarcea <gt...@um...> wrote: > >> > >> Yep, the comment is out of date. I'm pretty sure there is a patch > >> hanging around somewhere that added support for deadlines on lutex > >> platforms as well. > |
From: Nathan F. <fr...@gm...> - 2010-03-04 19:15:27
|
On Thu, Mar 4, 2010 at 2:08 PM, V. Glenn Tarcea <gt...@um...> wrote: > Does this mean that the (L)utex code goes away? On the Mac it is currently > using (L)utexes as opposed to (F)utexes. Futexes are a Linux-only feature. Other platforms use lutexes as a poor man's replacement for futexes. -Nathan |
From: V. G. T. <gt...@um...> - 2010-03-04 19:35:19
|
Hi Nathan, Thanks. What I was interpreting from the email exchange, perhaps incorrectly, was that a form of (F)utex had been extended to all the other platforms. That is there is a pthreads-futex.c file that in theory could be used on all the platforms that don't have native futex support. I took David's email to mean that something like this was implemented for the platforms that don't have native futexes. David: Is this the case, or did the extensions you are talking about apply just to platforms that have a form of native support? Thanks, Glenn V. Glenn Tarcea gt...@um... > -----Original Message----- > From: Nathan Froyd [mailto:fr...@gm...] > Sent: Thursday, March 04, 2010 2:15 PM > To: V. Glenn Tarcea > Cc: David L. Rager; sbc...@li... > Subject: Re: [Sbcl-devel] Question on Futex Comment (Another MacOSX > related item) > > On Thu, Mar 4, 2010 at 2:08 PM, V. Glenn Tarcea <gt...@um...> wrote: > > Does this mean that the (L)utex code goes away? On the Mac it is > currently > > using (L)utexes as opposed to (F)utexes. > > Futexes are a Linux-only feature. Other platforms use lutexes as a > poor man's replacement for futexes. > > -Nathan > |
From: David L. R. <ra...@cs...> - 2010-03-04 20:11:04
|
Hi Glenn, I implemented the timeout feature for all of the platforms, which included both lutexes and futexes. IIRC, this covered three multi-threading build+platform options: futexes on linux, lutexes on linux, and lutexes on darwin. I wasn't able to test the lutex on darwin case, but I think the "lutex on linux" case could reasonably suffice for that test. On linux, you can achieve the lutex vs. futex option by pushing sb-lutex onto the features list when you compile SBCL. Revisions from the pdf on page 18: "dicated" should be "predicated" "viously failed" should be "previously failed" Perhaps you already have the experience and permissions to make these changes, but before you update the patch, I'd recommend you get buy-in from someone that can review and submit such a patch to the trunk. Personally, I'm putting off the updating of my patch until I need to upgrade the version of SBCL that I use. But, I'd be happy to update it if said buy-in existed. Please feel free to ask further questions, as I'm quite interested in seeing the timeout feature added. At this point, I've wanted it for over three years. Thanks, David On Thu, Mar 4, 2010 at 1:35 PM, V. Glenn Tarcea <gt...@um...> wrote: > Hi Nathan, > > Thanks. What I was interpreting from the email exchange, perhaps > incorrectly, was that a form of (F)utex had been extended to all the other > platforms. That is there is a pthreads-futex.c file that in theory could be > used on all the platforms that don't have native futex support. I took > David's email to mean that something like this was implemented for the > platforms that don't have native futexes. > > David: Is this the case, or did the extensions you are talking about apply > just to platforms that have a form of native support? > > Thanks, > > Glenn > > V. Glenn Tarcea > gt...@um... > > >> -----Original Message----- >> From: Nathan Froyd [mailto:fr...@gm...] >> Sent: Thursday, March 04, 2010 2:15 PM >> To: V. Glenn Tarcea >> Cc: David L. Rager; sbc...@li... >> Subject: Re: [Sbcl-devel] Question on Futex Comment (Another MacOSX >> related item) >> >> On Thu, Mar 4, 2010 at 2:08 PM, V. Glenn Tarcea <gt...@um...> wrote: >> > Does this mean that the (L)utex code goes away? On the Mac it is >> currently >> > using (L)utexes as opposed to (F)utexes. >> >> Futexes are a Linux-only feature. Other platforms use lutexes as a >> poor man's replacement for futexes. >> >> -Nathan >> > > > |
From: David L. R. <ra...@cs...> - 2010-03-04 20:15:25
|
> Perhaps you already have the experience and permissions to make these > changes, but before you update the patch, I'd recommend you get buy-in > from someone that can review and submit such a patch to the trunk. > Personally, I'm putting off the updating of my patch until I need to > upgrade the version of SBCL that I use. But, I'd be happy to update > it if said buy-in existed. PS -- Perhaps the fact that there's been so much discussion about this code recently indicates that it's currently in a partially broken state. If that's true, perhaps there's less at stake concerning the risk of incorporating such a patch. But, I can also understand the opposite perspective -- that we should isolate changes and get each change working before making the next. Because, otherwise successive changes risk snowballing SBCL into a state that doesn't function at all. |
From: Paul K. <pv...@pv...> - 2010-03-04 22:47:31
|
(resending from an address I'm certain is subscribed to the list) On 2010-03-04, at 7:32 AM, Nikodemus Siivola wrote: > On 4 March 2010 14:05, Glenn Tarcea <gt...@um...> wrote: > >> I can try that. I'm still learning what can and can't be done and wasn't aware of this >> ability. But I'm having fun digging in :-) > >> I'm not so sure I understand all the interactions but I'm going to see if I can put >> deadline support in when using lutexes. It looks like MacOS is now supporting the >> pthread_foo_timedbar() functions that the comment was referring to. > > Yep, the comment is out of date. I'm pretty sure there is a patch > hanging around somewhere that added support for deadlines on lutex > platforms as well. I think the right way to do it is to use mach's interfaces directly. The native synchronisation primitives on OS X are (generalised) semaphores; with some luck, they'll be more robust and performant than the pthread compatibility layer. The semaphores are generalised to easily represent wait queues (by not allowing the count to become positive). In addition to the usual signal (post) and wait/timed_wait, they also support: - semaphore_signal_all (wait queue broadcast) - semaphore_wait_signal (atomically wait on one semaphore and signal another) - semaphore_timedwait_signal - semaphore_signal_thread (signal a single thread without increasing the semaphore's count) These translate directly into syscalls, so we can hope they won't break as easily as pthread's stuff. Even better: they're represented as unsigned ints (mach port ids) in the userland! We could also use the thread control API to stop the world instead of using unix signals (thread_suspend) [pseudo-atomic isn't hard to get right]. [EDIT: we could also handle most memory faults directly in the mach message pumping thread...] Paul Khuong |
From: Glenn T. <gt...@um...> - 2010-03-04 23:43:21
|
Hmm - interesting. Here is a nice link: http://developer.apple.com/mac/library/documentation/Darwin/Conceptual/KernelProgramming/synchronization/synchronization.html I also didn't realize there was a (2006) MacOSX internals book out (for example on google books: http://books.google.com/books?id=K8vUkpOXhN4C&pg=PA1219&lpg=PA1219&dq=macosx+semaphore_signal_all&source=bl&ots=OJnmWWWuYx&sig=xpKZ-GuWYaSkxi3qOHDpSJcCJLQ&hl=en&ei=B0OQS623CYOANqXWifwM&sa=X&oi=book_result&ct=result&resnum=3&ved=0CAwQ6AEwAg#v=onepage&q=&f=false) or at Amazon (US): http://www.amazon.com/Mac-OS-Internals-Systems-Approach/dp/0321278542 I'll need to do some reading. Thanks for the pointers! Glenn V. Glenn Tarcea gt...@um... On Mar 4, 2010, at 5:47 PM, Paul Khuong wrote: > (resending from an address I'm certain is subscribed to the list) > On 2010-03-04, at 7:32 AM, Nikodemus Siivola wrote: >> On 4 March 2010 14:05, Glenn Tarcea <gt...@um...> wrote: >> >>> I can try that. I'm still learning what can and can't be done and wasn't aware of this >>> ability. But I'm having fun digging in :-) >> >>> I'm not so sure I understand all the interactions but I'm going to see if I can put >>> deadline support in when using lutexes. It looks like MacOS is now supporting the >>> pthread_foo_timedbar() functions that the comment was referring to. >> >> Yep, the comment is out of date. I'm pretty sure there is a patch >> hanging around somewhere that added support for deadlines on lutex >> platforms as well. > > I think the right way to do it is to use mach's interfaces directly. The native synchronisation primitives on OS X are (generalised) semaphores; with some luck, they'll be more robust and performant than the pthread compatibility layer. The semaphores are generalised to easily represent wait queues (by not allowing the count to become positive). In addition to the usual signal (post) and wait/timed_wait, they also support: > - semaphore_signal_all (wait queue broadcast) > - semaphore_wait_signal (atomically wait on one semaphore and signal another) > - semaphore_timedwait_signal > - semaphore_signal_thread (signal a single thread without increasing the semaphore's count) > > These translate directly into syscalls, so we can hope they won't break as easily as pthread's stuff. Even better: they're represented as unsigned ints (mach port ids) in the userland! > > We could also use the thread control API to stop the world instead of using unix signals (thread_suspend) [pseudo-atomic isn't hard to get right]. > [EDIT: we could also handle most memory faults directly in the mach message pumping thread...] > > Paul Khuong > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > |
From: Paul K. <pv...@pv...> - 2010-04-12 00:38:48
|
On 2010-03-04, at 5:47 PM, Paul Khuong wrote: > I think the right way to do it is to use mach's interfaces directly. The native synchronisation primitives on OS X are (generalised) semaphores; with some luck, they'll be more robust and performant than the pthread compatibility layer. The semaphores are generalised to easily represent wait queues (by not allowing the count to become positive). In addition to the usual signal (post) and wait/timed_wait, they also support: > - semaphore_signal_all (wait queue broadcast) > - semaphore_wait_signal (atomically wait on one semaphore and signal another) > - semaphore_timedwait_signal > - semaphore_signal_thread (signal a single thread without increasing the semaphore's count) > > These translate directly into syscalls, so we can hope they won't break as easily as pthread's stuff. Even better: they're represented as unsigned ints (mach port ids) in the userland! Actually, I'm starting to think we should use semaphore everywhere we don't have futexes: unlike pthread's primitives, they (both mach and posix unnamed semaphores) return on interrupts. There's no need to allow interrupts around the calls (with the accompanying race condition windows) anymore! There's one issue: with mach semaphores, the code for condition variables is simple. Not so much with pure posix semaphores. On what other platform do we have threads, but not futexes? Solaris? Paul Khuong |
From: Nathan F. <fr...@gm...> - 2010-04-12 00:52:47
|
On Sun, Apr 11, 2010 at 8:38 PM, Paul Khuong <pv...@pv...> wrote: > Actually, I'm starting to think we should use semaphore everywhere we don't have futexes: unlike pthread's primitives, they (both mach and posix unnamed semaphores) return on interrupts. There's no need to allow interrupts around the calls (with the accompanying race condition windows) anymore! > > There's one issue: with mach semaphores, the code for condition variables is simple. Not so much with pure posix semaphores. On what other platform do we have threads, but not futexes? Solaris? I don't know if Solaris x86 supports threads. But FreeBSD is definitely another !futex threads platform. -Nathan |
From: Paul K. <pv...@pv...> - 2010-04-12 01:11:09
|
On 2010-04-11, at 8:52 PM, Nathan Froyd wrote: > On Sun, Apr 11, 2010 at 8:38 PM, Paul Khuong <pv...@pv...> wrote: >> Actually, I'm starting to think we should use semaphore everywhere we don't have futexes: unlike pthread's primitives, they (both mach and posix unnamed semaphores) return on interrupts. There's no need to allow interrupts around the calls (with the accompanying race condition windows) anymore! >> >> There's one issue: with mach semaphores, the code for condition variables is simple. Not so much with pure posix semaphores. On what other platform do we have threads, but not futexes? Solaris? > > I don't know if Solaris x86 supports threads. But FreeBSD is > definitely another !futex threads platform. I believe we use umtx (pretty much futexes) on fbsd now. Paul Khuong |
From: Tobias C. R. <tc...@fr...> - 2010-04-16 22:10:16
|
Paul Khuong <pv...@pv...> writes: > On 2010-03-04, at 5:47 PM, Paul Khuong wrote: >> I think the right way to do it is to use mach's interfaces >> directly. The native synchronisation primitives on OS X are >> (generalised) semaphores; with some luck, they'll be more robust and >> performant than the pthread compatibility layer. The semaphores are >> generalised to easily represent wait queues (by not allowing the >> count to become positive). In addition to the usual signal (post) >> and wait/timed_wait, they also support: - semaphore_signal_all (wait >> queue broadcast) - semaphore_wait_signal (atomically wait on one >> semaphore and signal another) - semaphore_timedwait_signal - >> semaphore_signal_thread (signal a single thread without increasing >> the semaphore's count) >> >> These translate directly into syscalls, so we can hope they won't >> break as easily as pthread's stuff. Even better: they're represented >> as unsigned ints (mach port ids) in the userland! > > Actually, I'm starting to think we should use semaphore everywhere we > don't have futexes: unlike pthread's primitives, they (both mach and > posix unnamed semaphores) return on interrupts. There's no need to > allow interrupts around the calls (with the accompanying race > condition windows) anymore! > > There's one issue: with mach semaphores, the code for condition > variables is simple. Not so much with pure posix semaphores. On what > other platform do we have threads, but not futexes? Solaris? How do mach semaphores look like that makes it simple? -T. |
From: Paul K. <pv...@pv...> - 2010-04-17 19:11:44
|
On 2010-04-16, at 6:07 PM, Tobias C. Rittweiler wrote: > Paul Khuong <pv...@pv...> writes: >> There's one issue: with mach semaphores, the code for condition >> variables is simple. Not so much with pure posix semaphores. On what >> other platform do we have threads, but not futexes? Solaris? > > How do mach semaphores look like that makes it simple? /usr/include/mach/semaphore.h: [...] extern kern_return_t semaphore_wait_signal (semaphore_t wait_semaphore, semaphore_t signal_semaphore); Atomically releases signal_semaphore and enqueues the calling thread on wait_semaphore. It's probably a bad sign that the function is basically undocumented. Paul Khuong |