<!-- MHonArc v2.4.4 -->
<!--X-Subject: [MUD-Dev] Re: atomic functions -->
<!--X-From-R13: "Tryvk O. Qebrf" <sryvkNkf1.fvzcyrk.ay> -->
<!--X-Date: Fri, 4 May 1998 23:25:10 -0700 -->
<!--X-Message-Id: 199805051252.OAA14086#xs1,simplex.nl -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, [MUD-Dev] Re: atomic functions</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:felix#xs1,simplex.nl">
</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>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00385.html">Previous</a>
| <a href="msg00388.html">Next</a>
]
Thread:
[ <a href="msg00557.html">Previous</a>
| <a href="msg00464.html">Next</a>
]
Index:
[ <A HREF="author.html#00386">Author</A>
| <A HREF="#00386">Date</A>
| <A HREF="thread.html#00386">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>[MUD-Dev] Re: atomic functions</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: [MUD-Dev] Re: atomic functions</LI>
<LI><em>From</em>: "Felix A. Croes" <<A HREF="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</A>></LI>
<LI><em>Date</em>: Tue, 5 May 1998 14:52:12 +0200 (MET DST)</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: "Petidomo List Agent -- Kanga.Nu version" <<A HREF="mailto:petidomo#kanga,nu">petidomo#kanga,nu</A>></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
Jon A. Lambert <jlsysinc#ix,netcom.com> wrote:
> On 5 May 98 at 1:52, Felix A. Croes wrote:
>[...]
> > Hmm... what is immediately obvious is that the worst-case behaviour
> > of S&S is a total lock-up, while C&C is guaranteed to be always
> > executing at least one event that will complete (if any events are
> > being executed at all). This suggests that C&C will perform better
> > if there are many conflicts. On the other hand, S&S offers the
> > programmer more ways to handle those conflicts.
>
> Oh no, deadlocks/lock-up are impossible because of spin-locking. That's
> why I was illustrating the two extremes of standard locking mechanisms.
Well, spin-locking by itself can prevent simple deadlocks, but not
complex ones. Take the following worst-case scenario:
N events are executing concurrently in N different objects. Each
event attempts to change, in random order, a property in each of
the N-1 other objects. In between every two property changes by
an event is an interval of fixed duration T, of such length that
the entire event is of maximum duration.
Using spin-locking in this scenario, events may be wrangling over
resources without <any> of them succeeding. Since all of them are
equally unsuccesful, increasing the priority of failing events will
not help. Until the system starts executing events single-threadedly,
or decreases the amount of events executed concurrently to such a
degree that it becomes likely that one of them will succeed, none of
the events will complete at all.
> I don't see how any threads are guaranteed execution in C&C, unless they
> are evntually escalated to single-threading as per your earlier
> reference. How does atomic prevent another thread from accessing and
> updating objects, unless you single thread/task it?
What I wrote is wrong -- if N events are executing and the first
one to complete succeeds, then the ones that complete after that
may all fail, so after completion of the first event, none of
the events executing at that moment will succeed. But in C&C,
an event that is itself doomed cannot block the progress of
another event. Since an event can only be doomed by another
event that already completed successfully, progress is guaranteed
in the system as a whole. In the worst case scenario above, one
event would immediately complete successfully.
Felix Croes
--
MUD-Dev: Advancing an unrealised future.
</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="00464" HREF="msg00464.html">[MUD-Dev] Re: atomic functions</A></strong>
<ul compact><li><em>From:</em> J C Lawrence <claw#under,engr.sgi.com></li></ul>
</UL></LI></UL>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00385.html">[MUD-Dev] Re: Character development [was Re: ]</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00388.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00557.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00464.html">[MUD-Dev] Re: atomic functions</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00386"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00386"><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>[MUD-Dev] Re: atomic functions</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00376" HREF="msg00376.html">[MUD-Dev] Re: atomic functions</A></strong>,
Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Mon 04 May 1998, 17:25 GMT
<UL>
<LI><strong><A NAME="00383" HREF="msg00383.html">[MUD-Dev] Re: atomic functions</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Mon 04 May 1998, 20:20 GMT
</LI>
<LI><strong><A NAME="00388" HREF="msg00388.html">[MUD-Dev] Re: atomic functions</A></strong>,
Joel Dillon <a href="mailto:emily#cornholio,new.ox.ac.uk">emily#cornholio,new.ox.ac.uk</a>, Tue 05 May 1998, 07:17 GMT
<UL>
<LI><strong><A NAME="00557" HREF="msg00557.html">[MUD-Dev] Re: atomic functions</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 13 May 1998, 21:32 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
<LI><strong><A NAME="00386" HREF="msg00386.html">[MUD-Dev] Re: atomic functions</A></strong>,
Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Tue 05 May 1998, 06:25 GMT
<UL>
<LI><strong><A NAME="00464" HREF="msg00464.html">[MUD-Dev] Re: atomic functions</A></strong>,
J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 07 May 1998, 22:58 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00433" HREF="msg00433.html">[MUD-Dev] Re: atomic functions</A></strong>,
Felix A. Croes <a href="mailto:felix#xs1,simplex.nl">felix#xs1,simplex.nl</a>, Wed 06 May 1998, 19:37 GMT
<UL>
<LI><strong><A NAME="00459" HREF="msg00459.html">[MUD-Dev] Re: atomic functions</A></strong>,
Shawn Halpenny <a href="mailto:malachai#iname,com">malachai#iname,com</a>, Thu 07 May 1998, 14:12 GMT
<UL>
<LI><strong><A NAME="00558" HREF="msg00558.html">[MUD-Dev] Re: atomic functions</A></strong>,
Jon A. Lambert <a href="mailto:jlsysinc#ix,netcom.com">jlsysinc#ix,netcom.com</a>, Wed 13 May 1998, 21:41 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</ul>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>
