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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b59b337045eece60 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!z72g2000hsb.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Structure of the multitasking server Date: Mon, 22 Sep 2008 05:47:13 -0700 (PDT) Organization: http://groups.google.com Message-ID: <29fcd27f-aefd-4787-b8f6-5f8a04bd0f42@z72g2000hsb.googlegroups.com> References: <8b4d1170-22e6-40d3-8ed1-096dc0163491@m36g2000hse.googlegroups.com> <1w9y1ocmu2cm3$.724p6fohqdvy$.dlg@40tude.net> <259e95c5-92e6-4200-bc6e-5f35d99336a9@l64g2000hse.googlegroups.com> <11dyqk0lqb1je.ap31n7jjew7l.dlg@40tude.net> <1ey0wvc4tun7g$.15u4xyef05055$.dlg@40tude.net> NNTP-Posting-Host: 128.141.45.227 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1222087633 23385 127.0.0.1 (22 Sep 2008 12:47:13 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 22 Sep 2008 12:47:13 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: z72g2000hsb.googlegroups.com; posting-host=128.141.45.227; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.1) Gecko/2008070206 Firefox/3.0.1,gzip(gfe),gzip(gfe) Xref: g2news1.google.com comp.lang.ada:2063 Date: 2008-09-22T05:47:13-07:00 List-Id: On 22 Wrz, 10:12, "Dmitry A. Kazakov" wrote: > > =A0 =A0 =A0 entry Get_Job (J : out Job_Type; Finished : out Boolean); > > Which is a bad pattern because it propagates task termination requests to > an entry point of some object (or another task) which usually have little > or nothing to do with the task termination issue. How is the special job any different in this aspect? It has exactly the same properties, just implicitly. > I don't like an extra output parameter, it is error-prone. Therefore I us= ed > a special value of Job_Type. In what way is a special value less error-prone than a separate flag? > There also exists a third variant with an > exception propagation. This assumes rendezvous. > This all is a matter of taste, because the (poor) pattern is same: the > knowledge about caller's termination is moved to the callee. In the version with protected objects the entity that triggers termination might be different from the one that invents job. In your version these different responsibilities are mixed. > > What about the following: in my version the main > > task (the one that invents jobs) can give the job to the worker task > > when it is still working on the previous one, so that the main task > > need not be blocked and can go on inventing more jobs. > > This is a very different task. You didn't say that you wanted to queue > jobs. And this is exactly the advantage of separate protected object - I didn't have to state all aspects and I was free to invent the part with queues later on. This flexibility is not provided by rendezvous, which would then require massive rework. > Anyway there is little sense to queue jobs to busy workers. There is a lot of sense. In particular, in my version the task that invents jobs is never blocked on interactions with workers. This is a big advantage, because such a blocking would disturb its own interactions with the environment and reduce its responsiveness. In your version with rendezvous the task that invents jobs has to block and during that time it cannot react to the events that drive it (keyboard input, network transmission, etc.). > A better > design would be: > > =A0 =A0Server --> Scheduler <-- Worker > > The jobs are queued to the scheduler. Workers ask it for jobs to do. > Scheduler could be a protected object or a task. Isn't it what I have proposed? > You *have* to wait, or else you must drop jobs. Which might be a perfectly legal handling policy. Or the main task could promptly reject requests so that clients can back off or try to find another, less busy server. > Anyway it is no problem in my design. Use selective accept (RM 9.7.1): > > =A0 =A0select > =A0 =A0 =A0 when not Empty (Queue) =A0=3D> accept Get (Work : out Job) do > =A0 =A0 =A0 =A0 =A0... -- A worker is here to get a job from the FIFO > =A0 =A0 =A0 end Get; > =A0 =A0or when not Full (Queue) =3D> accept Put (Work : out Job) do > =A0 =A0 =A0 =A0 =A0... -- A new job is to queue into the FIFO > =A0 =A0 =A0 end Put; > =A0 =A0or when Full (Queue) =3D> delay Time_Out; > =A0 =A0 =A0 ... -- Go to hell with your jobs! > =A0 =A0end select; But this looks like part of a separate task and the third branch still causes someone else to block. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada