Greg; Actually, the HANG is a reasonable alternative, but a better solution might be a timed READ. The time slice can be reclaimed upon the reception of an I/O, otherwise, the time slice is released to others. Subsequent global reads are usually satisfied from Cache and don't have the big overhead of a physical IO. Usually only the first one is expensive, subsequent accesses are cheap until the value changes (a WRITE always results in a physical IO, eventually, but may be clustered with other changes in the vacinity depending on the Cache flush algorythms). When you start talking about one node in a cluster serving as a LOCK Manager, then the rules are a bit different. The READ must be validated by the LOCK Manager who coordinates the global access for the cluster.
----- Original Message ----- From: "Gregory Woodhouse" <[EMAIL PROTECTED]> To: <hardhats-members@lists.sourceforge.net> Sent: Friday, July 29, 2005 10:30 PM Subject: Re: [Hardhats-members] Changeing/Activating PORT 9200 on the VistaLinuxServer > This is what I would have expected, at least on any systems where > MUMPS jobs are implemented as native threads or processes, but not > that many years ago, I've heard that people have reported finding > otherwise. But be that as it may, yielding the processor isn't the > only issue. You still don't want to "wake up" and perform an (albeit > global) I/O operation every second. I/O is still expensive, and not > yielding control of the processor (as was an issue in older Windows > and even Java implementations) isn't the only issue here. > > === > Gregory Woodhouse > [EMAIL PROTECTED] > > "The policy of being too cautious is > the greatest risk of all." > --Jawaharlal Nehru > > > On Jul 29, 2005, at 7:08 PM, Jim Self wrote: > > > This is a non-issue in MUMPS implementations that I have worked > > with in recent years, even > > a HANG of only one second in such a loop is sufficient to prevent > > it from consuming > > significant processing time while idle. > > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > _______________________________________________ > Hardhats-members mailing list > Hardhats-members@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/hardhats-members > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
