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: 103376,371144ace2969d7e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!feeder.news-service.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: C++ primer on multithreading Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <9014siefelqm$.18a5dek2p9s4h$.dlg@40tude.net> <4c5fb8d6-7785-4c9f-bcf0-2bf6b3bb2cb0@e26g2000vbz.googlegroups.com> Date: Fri, 22 Apr 2011 10:38:20 +0200 Message-ID: <1fr5ppc41ca7u.1oh598fh7fh9w.dlg@40tude.net> NNTP-Posting-Date: 22 Apr 2011 10:38:21 CEST NNTP-Posting-Host: e5cd0c1a.newsspool4.arcor-online.net X-Trace: DXC=2:ATlLGjLYE0YVY]kmLTlD4IUKk>Uj1a;Ng=1@NNF_@\C X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:19948 Date: 2011-04-22T10:38:21+02:00 List-Id: On Thu, 21 Apr 2011 14:03:20 -0700 (PDT), Maciej Sobczak wrote: > On Apr 21, 8:58�am, "Dmitry A. Kazakov" > wrote: > >> An interesting issue is the producer's behavior when the queue is full. I >> presume it would fail > > Or block. Being full is symmetric to being empty (hint: being full > means that you run out of empty space, which means that the reserve of > empty space is... empty :-) ). > >> or the queue may grow infinitely (:-)) > > There are no infinite computers yet. You will get the out of memory > condition, which in C++ is reported with an exception. This is handled > cleanly: mutex will be automatically unlocked and consumers will not > be affected. Real-life implementations of n-to-1 queue I made, wait for a finite time (typical response time limit 1-2s) and then throw an exception (e.g. BusyFault). This is an equivalent of timed entry call in Ada. The queue may grows up to a certain limit. >> You may need >> an additional pulse event to handle this more reasonably. > > What "pulse event"? They are not needed at all. Pulse event is an event reset automatically after notification all waiting threads. It can be used to unblock queueing threads which then start grabbing the mutex. The event is set when the consumer removes an item from the queue. Since pulse events are race condition exposed, certain care must be taken. BTW, there is no big difference on a single-core, but on a multi-core this design compared to Ada's protected objects is still a bit wasting, because producer threads may be really concurrent. An Ada implementation may just release the first blocked producer without activating the whole clique. In general multi-core threading is more fragile and has more "interesting" issues than single-core. We keep on detecting some minor glitches in our C++ software. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de