1997Q3/
<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: [MUD&#45;Dev]  C&#38;C and Event Rescheduling -->
<!--X-From-R13: pynjerapNphc.uc.pbz -->
<!--X-Date: from stimpy.globecomm.net [207.51.48.4] by in11.ibm.net id 870199825.24576&#45;1 Tue Jul 29 18:10:25 1997 CUT -->
<!--X-Message-Id: 199707291809.LAA10385#xsvr3,cup.hp.com -->
<!--X-Content-Type: text/plain -->
<!--X-Reference: 199707261742.TAA00453#regoc,srce.hr -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: [MUD-Dev]  C&amp;C and Event Rescheduling</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:clawrenc#cup,hp.com">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
      text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">

  <font size="+4" color="#804040">
    <strong><em>MUD-Dev<br>mailing list archive</em></strong>
  </font>
      
<br>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->

Date:&nbsp;
[&nbsp;<a href="msg00273.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00275.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Thread:&nbsp;
[&nbsp;<a href="msg00246.html">Previous</a>
&nbsp;|&nbsp;<a href="msg00289.html">Next</a>
&nbsp;]
&nbsp;&nbsp;&nbsp;&nbsp;
Index:&nbsp;
[&nbsp;<A HREF="author.html#00274">Author</A>
&nbsp;|&nbsp;<A HREF="#00274">Date</A>
&nbsp;|&nbsp;<A HREF="thread.html#00274">Thread</A>
&nbsp;]

<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: [MUD-Dev]  C&amp;C and Event Rescheduling</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI>
<LI><em>Subject</em>: Re: [MUD-Dev]  C&amp;C and Event Rescheduling</LI>
<LI><em>From</em>: <A HREF="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</A></LI>
<LI><em>Date</em>: Tue, 29 Jul 97 10:47:44 -0700</LI>
<LI><em>Reply-to</em>: <A HREF="mailto:claw#null,net">claw#null,net</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
In &lt;<A HREF="msg00246.html">199707261742.TAA00453#regoc,srce.hr</A>&gt;, on 07/26/97 
   at 10:53 AM, silovic#srce,hr (Miroslav Silovic) said:

&gt;&gt; Jon A. Lambert wrote:
&gt;&gt; &gt; 
&gt;&gt; &gt; &gt; From: clawrenc#cup,hp.com
&gt;&gt; &gt; &gt; Subject: [MUD-Dev]  C&amp;C and Event Rescheduling
&gt;&gt; &gt; &gt;
&gt;&gt; &gt; &gt;   Re: #5.  How do you determine that the object has changed during the
&gt;&gt; &gt; &gt; execution of the event?  I do this by always keeping an original copy
&gt;&gt; &gt; &gt; of the object to compare to the copy current in the DB and then do a
&gt;&gt; &gt; &gt; bit-wise comparison of the two objects.  The original copy is the
&gt;&gt; &gt; &gt; second copy made above for a modification.

&gt;I already specced the commit procedure for Cold, however, I went for
&gt;locking instead of copying. When you read an object, you obtain a
&gt;read lock on it. On write, the original is copied (in case of the
&gt;rollback), however, if any other task has a read lock on the object,
&gt;writer gets a rollback. If write suceeds, the object gets a write
&gt;lock - attempt to read a write-locked object causes rollback (these
&gt;are the basic rules, of course). Temporary copies are kept in a hash
&gt;table (hashed by object IDs), and thrown away on commit (along with
&gt;write locks). Advantage of this method is that things are not copied
&gt;unnecessarily (actually piling the copy in the hashtable is a simple
&gt;reference tweaking, and not actual tree-copying). 'Object' here
&gt;actually means object attribute, object method, object header (i.e.
&gt;objname and parents/children lists), file buffers and networking
&gt;buffers. Of course, none of this has been implemented yet. :)

Ignoring the lock semantics, in actual runtime effect this is almost
identical to what I'm doing.  However the net effect of the write lock
behaviour (Okay, dipping slightly into lock sematics) is to signal a
failed contention when the attempted access occurs rather than at
commit as I do.  This could allow a failed event to die and reschedule
much sooner than if it had to wait for the other contender to commit

Hurm.

It also changes the character fo the DB accesses.  In the lockless
model events compete to C&amp;C successfully.  Events with smaller
workings have an advantage at C&amp;C time, as do events with shorter run
times.  Its a question of who is in and out first.  Neither of those
points are true for your model.  For you, more or less, the first to
reach the base has it, holds it, and is guaranteed to commit
successfully (ignoring questions of needing to access an object which
another already has locked, which is not a safe assumption as below). 


Another potential problem is that your locking model opens itself to
infinite loops about the Dining Philosophers problem.  Without some
very interesting deadlock detection it is quite possible to have (say)
a minimal set of 3 events each of which attempts to lock various
objects and all of which get killed/rolled back because one of the
other two events already has the requested resource.  Consider:

  Objects A, B and C,

  Events X, Y and Z.

  X locks A.

  Y locks B.
  
  Z locks C

  X attempts to lock B and dies.

  Y attempts to lock C and dies.
  
  X restarts and locks A.

  Z attempts to lock A and dies.

  Y restarts and locks B.

  X attempts to lock B and dies.

  Z restarts and locks C.

  Y attempts to lock C and dies.

  ...etc.

This is a very simplistic case.  Add many more events, and have each
event attempt to access more than one object (5?  10?) and it becomes
almost probable.

Aside: Its not distributable, well, not in any sane manner, whereas
the lockless model rolls out there pretty easily, especially if you
allow objects to migrate between DB servers.

-- 
J C Lawrence                           Internet: claw#null,net
(Contractor)                           Internet: coder#ibm,net
---------------(*)               Internet: clawrenc#cup,hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...


</PRE>

<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<ul compact><li><strong>Follow-Ups</strong>:
<ul>
<li><strong><A NAME="00289" HREF="msg00289.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>
<ul compact><li><em>From:</em> Miroslav Silovic &lt;silovic#petra,zesoi.fer.hr&gt;</li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<UL><LI><STRONG>References</STRONG>:
<UL>
<LI><STRONG><A NAME="00246" HREF="msg00246.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></STRONG>
<UL><LI><EM>From:</EM> silovic#srce,hr (Miroslav Silovic)</LI></UL></LI>
</UL></LI></UL>
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00273.html">Re: [MUD-Dev]  Stories?</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00275.html">Re: [MUD-Dev] Graphic MUDS.</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00246.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00289.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00274"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00274"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>

<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] OT: Multi-threaded programming under linux</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00245" HREF="msg00245.html">Re: [MUD-Dev] OT: Multi-threaded programming under linux</A></strong>, 
Orion Henry <a href="mailto:ohenry#sdcc10,ucsd.edu">ohenry#sdcc10,ucsd.edu</a>, Sat 26 Jul 1997, 06:19 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00240" HREF="msg00240.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Fri 25 Jul 1997, 21:11 GMT
<UL>
<LI><strong><A NAME="00243" HREF="msg00243.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Sat 26 Jul 1997, 00:48 GMT
<UL>
<LI><strong><A NAME="00246" HREF="msg00246.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
Miroslav Silovic <a href="mailto:silovic#srce,hr">silovic#srce,hr</a>, Sun 27 Jul 1997, 00:42 GMT
<UL>
<LI><strong><A NAME="00274" HREF="msg00274.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Wed 30 Jul 1997, 01:10 GMT
<UL>
<LI><strong><A NAME="00289" HREF="msg00289.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
Miroslav Silovic <a href="mailto:silovic#petra,zesoi.fer.hr">silovic#petra,zesoi.fer.hr</a>, Wed 30 Jul 1997, 20:43 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00279" HREF="msg00279.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
clawrenc <a href="mailto:clawrenc#cup,hp.com">clawrenc#cup,hp.com</a>, Wed 30 Jul 1997, 06:50 GMT
</LI>
</UL>
<UL>
<li>&lt;Possible follow-up(s)&gt;<br>
<LI><strong><A NAME="00281" HREF="msg00281.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 30 Jul 1997, 10:28 GMT
<UL>
<LI><strong><A NAME="00315" HREF="msg00315.html">Re: [MUD-Dev]  C&amp;C and Event Rescheduling</A></strong>, 
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 31 Jul 1997, 23:34 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>

</ul>
<hr>
<center>
[&nbsp;<a href="../">Other Periods</a>
&nbsp;|&nbsp;<a href="../../">Other mailing lists</a>
&nbsp;|&nbsp;<a href="/search.php3">Search</a>
&nbsp;]
</center>
<hr>
</body>
</html>