[plt-scheme] Re: Shared resources for servlets

From: Dor Kleiman (dor at ntr.co.il)
Date: Tue Sep 9 17:21:29 EDT 2003

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?

	-----Original Message----- 
	From: Keith Frost [mailto:keithf at amnis.com] 
	Sent: ג 09/09/2003 18:31 
	To: plt-scheme at list.cs.brown.edu 
	Cc: 
	Subject: [plt-scheme] Re: Shared resources for servlets
	
	

	  For list-related administrative tasks:
	  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
	
	If I'm not mistaken, you've answered your own question:  just use a
	module.
	When subsequent servlets 'require' the same module, it is not reloaded, and
	any local state in the module is preserved.  If you need to serialize
	access to
	resources controlled by the module, you can create a semaphore to do so
	(see 'MzScheme Language Manual: Section 7.4'), so that servlets may block
	while waiting for the resource to become available.
	
	Which brings to mind a question I've had in the back of my mind, and I
	expect someone
	on this list could help me with.  Consider the common resource model
	"One writer -- many readers".  In other words, if a reader goes to
	access the resource,
	it needs only check whether there is a writer accessing it.  If so, it
	blocks until the
	writer releases it.  If not, it may go ahead, so that any number of
	readers can be
	simultaneously accessing the resource (a database, or even a file,
	say).  If a writer
	goes to access the resource, it has to check if there is another writer,
	or any readers,
	currently accessing it.  If so, it blocks until all readers and any
	writer have released it.
	
	What is the simplest, or a recommended, way to achieve this resource
	pattern using
	MzScheme's threads and semaphores?
	
	
	
	/ /
	
	
	

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20030909/fe8cf1be/attachment.html>

Posted on the users mailing list.