[plt-scheme] Cleanup on Servlet Timeout (Again)

On 2008-08-21, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 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.]

OK. I have semaphores on the brain right now, I just took the first OS
course at my university and wrote that code after we went through a
bunch of semaphore examples in class, including the regular
reader-writer problem. When you have a shiny new hammer. . . =)

>  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.

Thanks! I'm at work at the moment, but it looks like there's a lot for
me to chew on in there; I'll take a look tonight.

>  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.

Actually, I had a solution to this problem already, to use when the
writer throws an exception. Since each writer has its own sqlite
transaction, I can just signal to sqlite to do a rollback. It looks
like to do this properly I will have to move some DB calls into the
monitor itself.

Thanks,
    Henk Boom

>  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
>
>