gnumed-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]