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-7-bit Path: g2news1.google.com!news1.google.com!postnews.google.com!i76g2000hsf.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Structure of the multitasking server Date: Sun, 21 Sep 2008 14:27:13 -0700 (PDT) Organization: http://groups.google.com Message-ID: 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> NNTP-Posting-Host: 85.3.87.130 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1222032434 12940 127.0.0.1 (21 Sep 2008 21:27:14 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 21 Sep 2008 21:27:14 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: i76g2000hsf.googlegroups.com; posting-host=85.3.87.130; 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:2058 Date: 2008-09-21T14:27:13-07:00 List-Id: On 21 Wrz, 21:24, "Dmitry A. Kazakov" wrote: > On Sun, 21 Sep 2008 10:30:37 -0700 (PDT), Maciej Sobczak wrote: > > No problem with that. With separate protected object (instead of > > rendezvous) it is enough to do this: > > Of course there is a problem because conditional and timed entry calls may > not contain a "terminate" alternative. They don't have to. Again: entry Get_Job (J : out Job_Type; Finished : out Boolean); They have *no choice* but to get the Finished flag. Well, they don't have to react to it, but that seems to be very easy to spot in the code review or during the data flow analysis. > But the way you used protected > object looks like a design noise. Technically you just replaced a > rendezvous queue with a protected entry queue. The fact that this replacement is so obvious is exactly the reason why rendezvous as a language-level mechanism is nothing but a syntax sugar. > Instead of just server and > workers There is never "just server and workers". There are also jobs, queues (even if implicit) and lifetime management (your "poison pills"). > you have server, workers, channels and management stuff. Because it *is* there anyway. Trying to hide it? 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. In other words, main task and worker tasks need not wait for each other. This is not obvious from the state transitions that I've shown, but can be trivially implemented this way, without any massive modification of the tasks themselves: protected type Channel_State is procedure Post (J : in Job_Type); procedure Finish; entry Get_Job (J : out Job_Type; Finished : out Boolean); function Can_Accept_New_Job return Boolean; private Job_Pending : Boolean := False; Should_Finish : Boolean := False; Job_To_Do : Job_Type; end Channel_State; This code makes it easy to go to real queue with capacity > 1. This is not so easy in your version with rendezvous, where the main task has to always *wait* until some of the worker will be willing to pick up the new job (that's the whole point of rendezvous). Obviously, there are fewer opportunities for concurrency in your version. What would you have to do to have this increased concurrency in your version? Would you still claim it to be simpler? > The second problem which adds complexity is server to worker 1-n > communication. Should be n-1 worker to server, simpler (classic > client-server) and more efficient too. I'd prefer producer + queue + N consumers. Still a protected object in the middle. > Due to complexity you have overlooked to make a channel idle again after a > job is done. Yes, I have overlooked it, but now I would not make it this way. I would make it as describe above, to benefit from the increased concurrency. > And note, > that the type Channel cannot call to the procedure Finish to set Shut_Down > from its Finalize (if it were controlled). That's right and this is why I asked here about different design options. > > There is no need to introduce any special type of job ("poison pill"). > > Job carries the parameters of a worker. You used it too, under the name > Job_Type. But in my case the Job_Type need not contain the special "poison" value. Let's say that the Job_Type is a matrix that has to be reversed. There is no place for the "poison" value in the matrix itself, so the Job_Type would need to be extended (a record with additional flag, perhaps?) to cover it, but then the pollution of the type would be very explicit. > > Above, the job space is not polluted with task lifetime management > > concepts - these should be kept separate. > > You have polluted it with the procedure Finish, that has to be called > outside the worker tasks. I did not pollute the Job_Type (the matrix to be reversed), only the Channel_State - which is there exactly for everything that is related to managing the pipeline. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada