[plt-scheme] RE: Shared resources for servlets
Here's a quck draft (probably would need a bit of debugging, I have no DrScheme on this machine):
(module lock mzscheme
(define read/write-object
(class
(define (read) 'todo)
(define (write to-write) 'todo)))
(define lockable-object
(class
(define reading 0)
(define wrining? #f)
(init-field obj)
(define (open-read)
(if writing?
(begin (sleep) (open-read))
(set! reading (+ reading 1))))
(define (close-read)
(set! reading (- reading 1)))
(define (open-write)
(if (or writing? (> reading 0))
(begin (sleep) (open-write))
(set! writing? #t)))
(define (close-write)
(set! writing? #f))
(define (read)
; returns current value.
; Copies it first so it doesn't change when writing later on
(open-read)
(let ([r (send obj read)])
(close-read)
r)))
(define (write to-write)
(open-write)
(send obj write to-write)
(close-write)))))
Now all you have to do is fill in (read) and (write to-write) in read/write-object.
(define lo (instantiate lockable-object () [obj 'insert-read/write-object-here]))
(send lo read)
(send lo write 'value)
-----Original Message-----
From: Keith Frost [mailto:keithf at amnis.com]
Sent: ג 09/09/2003 22:40
To: Dor Kleiman
Cc: plt-scheme at list.cs.brown.edu
Subject: Re: Shared resources for servlets
Dor Kleiman wrote:
> I'm not sure that would work.
> Consider this:
> 3 readers are reading. A writer comes and blocks. Then a reader comes
> and joins in, blocking the writer even longer. This could block
> indefinitely, which won't be very good, would it?
Well, this is a simple model. You point out that it has the problem
that writers can be denied service indefinitely, if there is a sufficient
volume of readers. This is true. One can devise a more complex
model, such as one where (for example) a writer sends a request,
and new readers are blocked until that request is satisfied. But first,
I just want to know how to implement the simple model!
Keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20030910/baed299b/attachment.html>