Re: [racket-dev] Kill-safe, single-write, blocking box (was Re: scheme_sema_post_all)
On 2011-10-22 11:42 AM, Matthew Flatt wrote: > I think you could get this behavior by creating a manager thread when > you create the new kind of box. If threads are too heavyweight, though, > you can get the effect of a primitive by using `ffi/unsafe/atomic'. Of course! Using a thread to manage the cell is straightforward and will obviously work. I guess my imagination failed me indeed! Thanks for the pointer to ffi/unsafe/atomic. I'll see if something interesting can be done with that, as well. Regards, Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] Kill-safe, single-write, blocking box (was Re: scheme_sema_post_all)
I think you could get this behavior by creating a manager thread when you create the new kind of box. If threads are too heavyweight, though, you can get the effect of a primitive by using `ffi/unsafe/atomic'. At Sat, 22 Oct 2011 10:24:27 -0400, Tony Garnock-Jones wrote: > On 2011-10-22 9:43 AM, Tony Garnock-Jones wrote: > > Nothing like the 20 seconds or so after a post to make one question > > oneself. Could it be that semaphore-peek-evt could be used to get what I > > need? I'll experiment. > > The answer is "almost", i.e. "no". But scheme_sema_post_all doesn't do > what I want either. And I don't think having a thread issue an infinite > sequence of (channel-put)s can be used either. I think I need something > else. Something primitive, maybe. > > - If I use semaphore-peek-evt or scheme_sema_post_all, I still have a >problem with kill safety, because I have to do something like: > (when (semaphore-try-wait? (blocking-box-used b)) >(set-blocking-box-cell! b the-value) >(semaphore-post (blocking-box-ready b))) >...which might be killed between the try-wait and the post. > > - If I use a thread issuing an infinite sequence of channel-puts, > (thread (lambda () > (when (semaphore-try-wait? (blocking-box-used b)) > (let loop () > (channel-put c v) > (loop) >...the custodian could be shut down at some point. Trying the same >trick as the buffered async channels doesn't work here, because I'd >need to know which thread to thread-resume when I checked the box's >value, and to do that I'd need a kill-safe box that can be written >into only once, which is an infinite regress. > > It looks like I need something like a cross between CAS and a semaphore. > > Perhaps I'm having imagination failure here. Is there something I'm > overlooking that would get me an event to wait on until a value arrives, > and that enforces that second and subsequent value-setting attempts do > not succeed? > > (This is closely related to E's Promises and less closely related to > Scheme's delay/force.) > > Regards, > Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
[racket-dev] Kill-safe, single-write, blocking box (was Re: scheme_sema_post_all)
On 2011-10-22 9:43 AM, Tony Garnock-Jones wrote: > Nothing like the 20 seconds or so after a post to make one question > oneself. Could it be that semaphore-peek-evt could be used to get what I > need? I'll experiment. The answer is "almost", i.e. "no". But scheme_sema_post_all doesn't do what I want either. And I don't think having a thread issue an infinite sequence of (channel-put)s can be used either. I think I need something else. Something primitive, maybe. - If I use semaphore-peek-evt or scheme_sema_post_all, I still have a problem with kill safety, because I have to do something like: (when (semaphore-try-wait? (blocking-box-used b)) (set-blocking-box-cell! b the-value) (semaphore-post (blocking-box-ready b))) ...which might be killed between the try-wait and the post. - If I use a thread issuing an infinite sequence of channel-puts, (thread (lambda () (when (semaphore-try-wait? (blocking-box-used b)) (let loop () (channel-put c v) (loop) ...the custodian could be shut down at some point. Trying the same trick as the buffered async channels doesn't work here, because I'd need to know which thread to thread-resume when I checked the box's value, and to do that I'd need a kill-safe box that can be written into only once, which is an infinite regress. It looks like I need something like a cross between CAS and a semaphore. Perhaps I'm having imagination failure here. Is there something I'm overlooking that would get me an event to wait on until a value arrives, and that enforces that second and subsequent value-setting attempts do not succeed? (This is closely related to E's Promises and less closely related to Scheme's delay/force.) Regards, Tony _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
