[plt-scheme] Cleanup on Servlet Timeout (Again)
At Wed, 20 Aug 2008 22:48:55 -0400, "Henk Boom" wrote:
>
> http://www.cs.utah.edu/plt/kill-safe/
>
> Now that I finally have time to devote to this, I've taken a look.
> From what I understand, though, this technique only helps when your
> lock lasts only for the duration of your call to the resource.
Forget locks. Make a process that's in charge of the resource.
[The process is effectively an implementation of a readers+writer lock,
but this characterization is probably useful only if you're trained to
think in terms of locks instead of processes. The key is that you get
to implement the "lock" instead of trying to juggle primitive locks.]
The process representing the resource accepts reader requests and lets
them run them in parallel; when a reader asks to become a writer, then
the managing process waits for all the other readers to finish before
granting the conversion; if there's already a pending writer, then all
new writer-conversion requests are rejected. The process can see when a
reader/writer terminates, and it can adjust accordingly. The enclosed
"rwlock.ss" illustrates this implementation.
Depending on the domain, though, there's one more problem beyond
granting read and write access in a kill-safe way. What if a thread is
terminated while it's in write mode? The "rwlock.ss" implementation
treats termination the same as the completion, but that's valid only if
each atomic step in writing keeps the relevant data consistent.
Otherwise, you need some way to ensure that the write completes so that
the data is consistent.
If all you have is locks, then you're stuck on this second problem. If
you have a process, though, the solution is pretty easy: delegate the
writing work to the process that handles read and write access. (The
writing work has to be trusted in this case, in the sense that it won't
raise unexpected exceptions or things like that.) The enclosed
"rwlock-complete-write.ss" illustrates the generalization or
"rwlock.ss" to solve that problem.
BEWARE: a version of the enclosed code exposed a bug in `sync'. (An
array was improperly re-used when, for a non-zero N, `sync' receives N
`choice-evt's that contain no non-choice events plus M `choice-evts'
that contain a total of N+M non-choice events.) The bug is fixed in
SVN, and the enclosed code contains a dummy semaphore to work around
the bug.
Matthew
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rwlock.ss
URL: <http://lists.racket-lang.org/users/archive/attachments/20080821/76f9f598/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: rwlock-complete-write.ss
URL: <http://lists.racket-lang.org/users/archive/attachments/20080821/76f9f598/attachment-0001.ksh>