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 X-Google-Thread: a07f3367d7,8fa1dddecbe9cd04 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!de-l.enfer-du-nord.net!news.weisnix.org!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: How to determine if task is busy or not? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <063cfc19-a8fa-41af-b948-d4f8540cb2ab@o36g2000vbl.googlegroups.com> <4aef99b6-6ac6-4e0b-91d8-2a5320ea6e9c@l34g2000vba.googlegroups.com> Date: Sat, 8 Aug 2009 20:22:42 +0200 Message-ID: <11m01goasspup.x63didgf7t0x.dlg@40tude.net> NNTP-Posting-Date: 08 Aug 2009 20:22:41 CEST NNTP-Posting-Host: 4103fbab.newsspool2.arcor-online.net X-Trace: DXC=QK1hH@[P9?D74okIm;?DS@A9EHlD;3YcB4Fo<]lROoRA^YC2XCjHcbI3Lk`;3chNSGDNcfSJ;bb[EIRnRBaCd On Sat, 8 Aug 2009 07:59:51 -0700 (PDT), Maciej Sobczak wrote: > On 8 Sie, 13:27, "Dmitry A. Kazakov" > wrote: > >> The scheme described by Ludovic is not only simpler, it is also race >> condition free. The reverse scheme has a race condition in it. If you have >> asked if a task is idle, you do not know if it still is right now > > Depends. If it is the asking entity that is also providing the job, > then the problem above cannot happen. In other words, if the "manager" > asks the task whether it is busy or idle and the answer is "idle", > then that answer it true until the same manager provides new work > unit, because there is no other way for the task to switch from "idle" > to "busy". Which means that the manager can always safely handle a new > work unit to the "idle" task, no race is possible. As I said, only if single job supplier (manager) is here. In that case it is still a poor scheme because of polling. A better (I tempted to say proper) one is when idle tasks queue themselves into the pool of idle tasks maintained by the manager. But a protected object of tasks would be better here as well. > The advantage of such a setup is that the manager knows whether the > work can be handled *immediately* by any one of the tasks in the pool. > False negatives can be harmless, as long as the positives are > accurate. No, it is not an advantage. 1. Job is done to get a result, it is a lengthy process, so there is a worker to perform it asynchronously. Until the job is done it is of little interest whether it has been started or not. (Some interest exists if jobs are cancelable if not initiated) 2. The manager is only a mediator here. If a job cannot be started immediately what the manger is supposed to do? If it does not cancel the job, the only option is to wait. This is what the job queue is for. > Using a queue, as suggested by Ludovic, makes sense only when the work > units can *wait* for being processed. This might or might not be the > case. See above. If there is some service timeout a queue is serviced by a monitor task (a special "mister no" worker). Still better. > There are examples of systems where either of these schemes are good > (batch processing vs. real-time?). I would not say that one is better > than another. > > To Tomek - the simplest way to deploy your original idea is to use a > flag (Busy/Idle - an enumeration type is perfect here), which is > shared and used by both the worker task and its manager. Protected > object is a proper solution here and you might even use the same > protected object for managing both the flag and the work unit itself. No, you don't need any extra shared data. Do conditional entry call do determine if the worker is ready: task body Worker is begin loop accept New_Job (Work_Item : in out Job); ... -- Service end loop; end Worker; The manager does a conditional entry call (RM 9.7.3): select Worker.New_Job (Thing_To_Do); else -- The chap is busy ... end select; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de