The Dining Philosophers in REST
Thu, 16 Aug 2001 08:36:10 -0700
> critical sections which are usually protected by mutexes are
> implemented in the waiters, and each is engaged through a single HTTP
I've always wanted to try monitors via
HTTP transport of the critical data for
entry/exit/wait, but have never had an
POST as Compare&SwapXML?
> Responses from these guys are explicitly set to be
> non-cacheable, and the client does *not* make decisions based on
> these state snapshots.
That may be a bit limiting. If the
POSTs deal with deltas, then it can
be valuable to have a stale* GET in
a local cache. Think DB+journal, or
GUI+events, or perhaps best yet, a
good old CLI, where any "show me the
current state" requests are mostly
infrequently interspersed among the
"modify the state" commands.
* In paperspace, I find my 1998 GTE
phone book to be better, although
stale, than the 2001 PacBell one.
"The new number is...", 411, and
the web suffice to get any needed
patches for "current" state.
> Since Sybase at the time did page-level locking,
Some of my favorite bits from Gray and
Reuter's _Transaction Processing_ are
where they say "Many people have learned
the following adage the hard way: *page
granularity is fine, unless you need
finer granularity*", and go on to state
both the virtues of page granularity and
common conditions under which it becomes
> [contrast] the design of the Berkeley sockets interface with
> the way that networks are abstractly represented in Plan 9.
Yet another idea I haven't had an excuse
to implement (surely someone has already
done this?) is to add a chroot() like
call to the Linux kernel to say "neither
I nor my descendants will use the socket
subsystem". I suspect under Plan 9 (or
under the original Unix abstractions!)
such functionality would just fall out of
the namespace handling.