From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!goblin3!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Tue, 6 May 2014 21:07:34 +0200 Organization: cbb software GmbH Message-ID: <6ve3i79bog3t.uojmmyur7v75.dlg@40tude.net> References: <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com> <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: number.nntp.dca.giganews.com comp.lang.ada:186274 Date: 2014-05-06T21:07:34+02:00 List-Id: On Tue, 06 May 2014 12:22:59 -0400, Robert A Duff wrote: > Brad Moore writes: > >> However, it might make sense to specify certain primitive subprograms of >> a type as being task safe. > > What exactly do you mean by "task safe", either for a type, or for > a subprogram? E.g. if Element is task safe, does that mean calls > to Element are atomic with respect to each other? It means, in my interpretation, that the post-condition of the operation [and the object's invariant] is true for any number of tasks Wi calling the operation independently at any point Ti of real-time. > If both Element > and Replace_Element are task safe, does that mean calls to Element > and Replace_Element are atomic; i.e. if one task calls Element, > and another calls Replace_Element, those two calls are serialized? No. It could be atomic in order to ensure the post-condition. > Why primitive subprograms? What about class-wide subprograms > declared in the same package? That was my question too. Presumably, primitive operations were considered building blocks for class-wide operations, which, under this assumption, would be safe per design for some, rather, weak [as you pointed below] post-conditions. > Does task safety imply absence of deadlock? Pragmatically, the answer could be no, if more than one object involved. Yes, for single object. Safety of any subset of a set of objects is stronger than safety of individual objects. > Suppose we have an atomic increment function (calls to it are > serialized), and Counter is initially 0, and one task does > "X := Incr (Counter);" and another task does "Y := Incr (Counter);". > A third task waits for those two to terminate, and then calls > procedure P, which prints X followed by Y. Is P task safe? See above, that depends on the post-condition of P. > I understand task safety in an informal way, but I'm not sure > how to decribe it formally. And if the definition depends on > the intent of the programmer (perhaps expressed in comments), > we can't expect a compiler to check it. ;-) Right. Minimally, the semantics must be stated formally using pre- and post-conditions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de