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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,36a29c2860aff686 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!feeder.news-service.com!94.75.214.39.MISMATCH!aioe.org!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Properties Date: Mon, 6 Dec 2010 17:33:56 -0600 Organization: Jacob Sparre Andersen Message-ID: References: <3b84c8e7-1a51-4a7c-9646-119f1fc51478@s4g2000yql.googlegroups.com> <4pnv7nl4cdui$.1n28i7lqk4mek$.dlg@40tude.net> <1k7367gtebsgm$.18auo6u3nfg34.dlg@40tude.net> <1u5dftkqqi68c.10079qnqyyfwb$.dlg@40tude.net> <15tv4yga36dpi$.1hc09dlbgcmqe.dlg@40tude.net> <18768dde-5817-40b9-aaa1-03c620ad7187@i32g2000pri.googlegroups.com> <1sp30ekj4pmer$.1753nbz1zyzid$.dlg@40tude.net> <2a3219cb-5793-4e5b-97aa-036da124ccba@y31g2000vbt.googlegroups.com> <0c899bff-c580-4b9f-9c94-b9226c089cde@j29g2000yqm.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1291678438 17519 69.95.181.76 (6 Dec 2010 23:33:58 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 6 Dec 2010 23:33:58 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Xref: g2news2.google.com comp.lang.ada:16800 Date: 2010-12-06T17:33:56-06:00 List-Id: "Maciej Sobczak" wrote in message news:acc754a9-4861-401a-a904-5f22efe852ac@z26g2000prf.googlegroups.com... >On Dec 3, 10:32 pm, "Randy Brukardt" wrote: > >> Indeed, I think that *any* library intended for general Ada usage ought >> to >> be task-safe to the extent that Ada.Text_IO and Ada.Containers are >> (access >> to different objects of the library by different tasks always work). > >What are different objects? The definition I use is the RM one: "non-overlapping" objects. Informally, these occur anytime you have parameters that are all distinct (none denoting parts of any of the others, taking into account renames and components, but generally not access values). Practically, if the implementation is a bunch of objects interconnected by access types, the individual objects should be task-safe; if the objects are components of a larger object, then task safety is probably a mistake. But that's too implementation-oriented a definition to use. There really can't a formal definition, unfortunately, because of the need to support portions of objects that aren't components but are managed as if they were. So we could argue about the exact definition all day. > Certainly, AARM does not allow several tasks to access distinct > elements of the same container - because, well, even though the > elements are different, they belong to the same container. In this case, the container is implicitly part of the cursor parameters. Note that I believe this is a design bug in the Ada.Containers; the container parameter ought to be explicit in all of these operations, including the reading ones. As they are defined currently, you would expect tasking to work on reading of different elements (and like Text_IO, it probably will work in practice). >> That >> surely includes GUI libraries. > >...where almost everything is a child of some bigger container. Here I disagree. A GUI is a bunch of cooperating objects; the organization is a loosely coupled. Just because a button has a parent window doesn't mean that the button isn't an independent object (it could be moved to a different parent, for instance). >I understand what you try to convey (and to a large extent I agree >with it), but the analogy with containers does not work. By that >analogy it should be forbidden to access two controls of the same >window from different tasks without additional synchronization. The problem here is that the containers specification is incorrect -- it doesn't properly expose the relationship with the container objects. Thus you are making the wrong analogy. (Given the specification given for reading container objects, task safety ought to be required. We didn't do that because we really meant it to work as if the container was explicitly given. This is also a problem in defining the behavior of the operations formally, and it prevents using prefix notation with these calls.) If your hypothetical GUI never allowed accessing the controls of a window without mentioning the name of the parent window, then I would in fact agree with your implementation. But I'd still want task-safety between windows. >> That's all that Claw guarantees >I can imagine that it was very expensive to achieve. It's not that hard to achieve, the problem is avoiding deadlock (since you have to be able to do operations in action routines). We would have had to do it in any case, given that we set up a separate task to handle messages. And, as noted above, the problems only really show up when you modify the "shape" of the GUI, adding or removing windows/controls. (Just directly reading or writing a control is not a problem.) Randy.