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=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.223.166 with SMTP id v36mr49029112yhp.45.1426277789492; Fri, 13 Mar 2015 13:16:29 -0700 (PDT) X-Received: by 10.140.41.104 with SMTP id y95mr800875qgy.7.1426277789476; Fri, 13 Mar 2015 13:16:29 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!z107no68475qgd.0!news-out.google.com!q90ni143qgd.1!nntp.google.com!z107no68474qgd.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 13 Mar 2015 13:16:29 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a02:120b:2c20:9060:6dd4:c8f7:e15d:cb67; posting-account=gRqrnQkAAAAC_02ynnhqGk1VRQlve6ZG NNTP-Posting-Host: 2a02:120b:2c20:9060:6dd4:c8f7:e15d:cb67 References: <8b4d1170-22e6-40d3-8ed1-096dc0163491@m36g2000hse.googlegroups.com> <71b51c8e-6bed-4156-9f52-31bef57b8575@googlegroups.com> <871tktuc9i.fsf@adaheads.sparre-andersen.dk> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Structure of the multitasking server From: gautier_niouzes@hotmail.com Injection-Date: Fri, 13 Mar 2015 20:16:29 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 2300 X-Received-Body-CRC: 2122470177 Xref: news.eternal-september.org comp.lang.ada:25165 Date: 2015-03-13T13:16:29-07:00 List-Id: Le vendredi 13 mars 2015 09:14:52 UTC+1, Dmitry A. Kazakov a =E9crit=A0: > You could add a wakeup event to prevent busy waiting. An alternative woul= d > be a waitable jobs queue. Wouldn't a delay instruction help ? > BTW, you seem have another problem. The drivers/workers are serviced alwa= ys > in the same order which would systematically choke ones near to the list > end. A usual solution of this problem is list walking entered at the poin= t > where it was left. Do you mean worker #1 would tend to be overworked compared to the others ? In the program I run - perhaps because the jobs are long: a few seconds num= ber crunching - it doesn't seem to be the case: Worker 1 362 jobs Worker 2 540 jobs Worker 3 652 jobs Worker 4 359 jobs Worker 5 366 jobs Worker 6 592 jobs Worker 7 371 jobs Worker 8 370 jobs G.