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: a07f3367d7,8fa1dddecbe9cd04 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!l34g2000vba.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: How to determine if task is busy or not? Date: Sat, 8 Aug 2009 07:59:51 -0700 (PDT) Organization: http://groups.google.com Message-ID: <4aef99b6-6ac6-4e0b-91d8-2a5320ea6e9c@l34g2000vba.googlegroups.com> References: <063cfc19-a8fa-41af-b948-d4f8540cb2ab@o36g2000vbl.googlegroups.com> NNTP-Posting-Host: 85.1.147.180 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1249743591 27040 127.0.0.1 (8 Aug 2009 14:59:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 8 Aug 2009 14:59:51 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: l34g2000vba.googlegroups.com; posting-host=85.1.147.180; 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.13) Gecko/2009073021 Firefox/3.0.13,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:7660 Date: 2009-08-08T07:59:51-07:00 List-Id: 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. The race can happen the other way round, though: the manager asks the task for its status, the task answers "busy" and the manager takes some decision based on this answer (move on to another task, perhaps?) even though it might not be true anymore (the task in question might be already "idle" by that time). This kind of race might be acceptable, though, at most at the price of underutilized on unbalanced server. 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. 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. 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. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada