[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] middleware upgrade
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] middleware upgrade |
Date: |
Thu, 22 Dec 2005 19:39:22 +0100 |
User-agent: |
Mutt/1.5.11 |
On Thu, Dec 22, 2005 at 08:26:29AM +0800, Syan Tan wrote:
> xmin piqued my interest again in distributed shared memory topic, and I went
> back and read about
> - is a DSM (distributed shared memory) protocol write-invalidate or
> write-update ? If write update, the writer blocks until all other copies
> on other clients are updated, whereas in write-invalidate, the readers are
> notified by replica managers that
> they have invalid copies, and must refetch their data.
GNUmed is then write-invalidate the way it's written now.
> gnumed is client -server, and uses postgres client-Listen-block / server -
> Notify system in order
> to implement DSM de facto . This means that in this specific function, gnumed
> is not single threaded ,
Exactly, it is not. It uses several threads to listen for
out-of-framework events (such as from PostgreSQL or from
XML-RPC clients).
> as it has to spawn a blocking thread that listens for updates,
Except that the "blocking" thread does a neverending pull
loop. Which is functionally equivalent to blocking.
> Is postgres's notify command blocking for the server ( server blocks waiting
> for aknowledgement of notify from all clients) ?
No, it does not wait for other clients.
> It probably should be, because all
> active clients need
> to acknowledge receipt of a single notify
It doesn't even guarantuee that there will be a 1:1
correspondence between initiated and delivered notifies. It
can happen that a client receives only one notify for a
given type if they were initiated in quick succession and
the client did not pick up the first before the second was
initiated).
> in order for total ordering to be
> preserved, otherwise a client could
> be operating on stale data, send an update based on the stale data, and then
> later receive a delayed notify message
Yes, but we protect against that with the xmin code.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346