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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8eff44ec1bcf8433 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-10-17 00:10:47 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!fr.usenet-edu.net!usenet-edu.net!asynchrone!proxad.net!feeder2-1.proxad.net!news2-1.free.fr!not-for-mail Message-ID: <3BCD2EC3.3B3C4498@free.fr> Date: Wed, 17 Oct 2001 09:09:55 +0200 From: Jean-Marc Bourguet X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Container reqs References: <9qctpn$lil$1@news.huji.ac.il> <3BCC01B1.18C18C98@free.fr> <3BCC6CB7.20BAA30D@boeing.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Guest of ProXad - France NNTP-Posting-Date: 17 Oct 2001 09:10:46 MEST NNTP-Posting-Host: 158.140.208.29 X-Trace: 1003302646 news2-1.free.fr 202 158.140.208.29 X-Complaints-To: abuse@proxad.net Xref: archiver1.google.com comp.lang.ada:14778 Date: 2001-10-17T09:10:46+02:00 List-Id: Jeffrey Carter wrote: > > Jean-Marc Bourguet wrote: > > > > I'm not for making a container "threadsafe" to the point where > > several tasks may modify the container without providing their > > synchronisation. > > In my experience > > * most containers are accessed only by one task > > * for those who are not, an explicit synchronisation is needed for > > other > > purpose as the container is not the only part member of the > > datastructure > > which has to be modified atomically. > > This is an interesting assertion, considering that a protected queue is > a useful and common form of intertask communication. I was probably not clear enough. Tasks savety is not something binary, it's something for which there is at least five levels. 0) the whole library can't be used by two tasks without explicit synchronisation because there is use of some features (global variables, COW datastructure build without considering tasking, ...) which make it totally unfit for that use. 1) you can work savely on different objects in different tasks but not access the same object in different tasks without synchronisation. 2) you can savely have read access to one object from different tasks but modifying accesses must be protected explicitly from other accesses. 3) there is a limited set of modifying accesses which can be issued simultaneously from different tasks. 4) whatever you do -- trying to modify the datastructure simultaneously via iterators from different tasks -- is save. >From my experience, * level 4 is useless because you still need synchronisation for other reasons when its whole generality is needed. Achieving it has a major performance impact (every operation has to be protected). * level 3 is usefull but the set of modifying access which make sense depend very much on the application. Your example is probably the only widely applicable one. Achieving this level has a important performance impact. * level 2 can be achieved with a small performance impact: there is no need for explicit synchronisation, one need simply to pay attention to the datastructure used and the way it is accessed. I think that one should aim for level 2 because: - this simplify the library (no need to have tasks save and tasks unsave version) - aiming level 3 whould imply major discussion about the set of operations needed with the risks of compromising to level 4. - I whould probably still encapsulate the ADT in an other type/package which export only the operations needed for the application with names related to the application. If one want to provide level 3, I'm for having separate tasks save and tasks unsave version and that the "task unsave" still provide level 2 saveness. Yours, -- Jean-Marc