220 17240 <2000ef45-bc5b-4453-8252-d78c7406afc8@isocpp.org> article Path: news.gmane.org!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Generic Parallel Computing (GPC) API Date: Sat, 4 Apr 2015 12:39:15 -0700 (PDT) Lines: 164 Approved: news@gmane.org Message-ID: <2000ef45-bc5b-4453-8252-d78c7406afc8@isocpp.org> References: <3be1928f-2116-4712-be20-7368682abf26@isocpp.org> <81e0ac7b-2e97-4ecc-8c37-c9851be3d81c@isocpp.org> <45d4c30d-72b4-474a-9df6-9efa17d4d0b1@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2296_244332204.1428176355096" X-Trace: ger.gmane.org 1428176359 2770 80.91.229.3 (4 Apr 2015 19:39:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 19:39:19 +0000 (UTC) Cc: tef@tentity.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLZJYWNDQIOJ64AVECRUBCNT46CW@isocpp.org Sat Apr 04 21:39:19 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YeTuY-00007u-Fb for gclcip-std-proposals@m.gmane.org; Sat, 04 Apr 2015 21:39:18 +0200 Original-Received: by iecat1 with SMTP id at1sf1991400iec.1 for ; Sat, 04 Apr 2015 12:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=5y5VtBRgu/7h80QCzLGJ+vl6070P67nGQGwaSxXNwdM=; b=irkXEV2VGZUTXSWC5z9fs2fApqTQrbv0iJsv1jgHjj9rof70wUGsx9i5zbRInCrwV0 u1MUJBIonDoqQW6mUWY8Qqc7uPCPNEQZ92D4ryYJrdL/DPSlhrIXdEFaS5FoDA4DN8A9 5JDGBoer5G7m+M89iLzgUc4GWl2eEqb05iFkEBj0VmTnH9rVZDfNqCaz1YHog+f25zHI OkeAs2N9akGnyctr4C2+u67vWGQ0qSlTokocCSGGkzj0dBRb73Z2IHOj2f9KFWsd8Fcz fZfmbXfFZ5miOnx74wzD+Lyu+39Vl55iguiSa8B1OgH8s86H8f2gYDV31HNu6Lf05XzU P20A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=5y5VtBRgu/7h80QCzLGJ+vl6070P67nGQGwaSxXNwdM=; b=Piw40JuDytOiXGK8C9YKPzzwT/14Enuwip7TN6qnCGm/AzDMilKThITCMHbiv8ET4H Ns/bchbbdtS9KZHV6iCITV4dNckJiva3JSb49meglLCjZ55GsTFN1l8LF/Y707RWKp5I c/tyzm+Sr9m48kuExe2cuPhWvsEimZ4aSpwmliRsmemN63YYjZ8ONfG+04mELvXGgUo+ gEyAAb045NPhUhYAxLazuEY5jKWqm60YREtFcHnVSTdDfEzbNQ6ANWUALG4kp6jiP434 alIcfUFLP+ZfIIr/pNb2Tdg8Q77NJrBsz+zQATVvBb4CJLUtKViPKJrse4KKBKRhHzzM tZTg== X-Gm-Message-State: ALoCoQlJlIeqHGjS7/6cZDE4j540wgcVBFM2V+siz/E6z167RcXO/NFcv/IrvS7Eo4ZrrWzwRkQt X-Received: by 10.42.53.80 with SMTP id m16mr10542199icg.3.1428176357526; Sat, 04 Apr 2015 12:39:17 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.47.154 with SMTP id v26ls1391435iov.99.gmail; Sat, 04 Apr 2015 12:39:16 -0700 (PDT) X-Received: by 10.50.18.47 with SMTP id t15mr165671igd.16.1428176356515; Sat, 04 Apr 2015 12:39:16 -0700 (PDT) In-Reply-To: <45d4c30d-72b4-474a-9df6-9efa17d4d0b1@isocpp.org> X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:17240 Archived-At: ------=_Part_2296_244332204.1428176355096 Content-Type: multipart/alternative; boundary="----=_Part_2297_502619564.1428176355096" ------=_Part_2297_502619564.1428176355096 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Now that I've read more of the documentation and have a better idea of the= =20 concepts involved... If I understand correctly, you start from the atomic= =20 concept of (work-queue + consumer-pool-of-size-N) In your particular system there is a singleton global (work-queue +=20 consumer-pool-of-size-LARGE) that you call "the thread pool", to which jobs= =20 can be submitted via gpc::fork(); and your system also supports=20 constructible-on-the-fly (work-queue + consumer-pool-of-size-1)s, which you= =20 call "qutexes" and to which jobs can be submitted via qutex::join(). If anything like this model were proposed for standardization, I'd hope=20 that it would standardize the underlying (work-queue +=20 consumer-pool-of-size-N) model, so that you could have=20 constructible-on-the-fly work-queues with consumer-pools of size 2 (for=20 example). Perhaps the atomic concept should even *be* split up, so that a= =20 single consumer-pool could pull from two different work-queues, etc. etc. Notice that a work-queue with only a single producer and/or only a single= =20 consumer can be implemented with greater efficiency than a work-queue with= =20 multiple producers and/or consumers, so there's an efficiency win there=20 that should be reflected in the library somehow. However, I don't think the= =20 "qutex" concept gets us anywhere close to where we ought to be in the end. =E2=80=93Arthur On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, t...@tentity.com wrote: > > Thanks.=20 > Now I am thinking "qumex" which abbreviation for *Qu*eue of *M*utual *Ex* > clusion.=20 > Would it be better? > > On Friday, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrote: >> >> On Friday, April 3, 2015 at 5:15:13 AM UTC-7, t...@tentity.com wrote: >>> >>> Quetex is Mutual Exclusion Queue. It eliminates blocking/waiting and= =20 >>> thread switching in comparison to mutexes and futures. >>> >>> gpc::quetex qtx; >>> >>> >> Not related to the semantics, but FYI, "quetex" looks like it ought to b= e=20 >> pronounced "kaytex", and you lose the pun. Consider "queuetex" or "qutex= "=20 >> instead. :) >> >> =E2=80=93Arthur >> > --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_2297_502619564.1428176355096 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Now that I've read more of the documentation and have a be= tter idea of the concepts involved... If I understand correctly, you start = from the atomic concept of

    (work-queue + c= onsumer-pool-of-size-N)

In your particular system = there is a singleton global (work-queue + consumer-pool-of-size-LARGE) that= you call "the thread pool", to which jobs can be submitted via gpc::fork()= ;  and your system also supports constructible-on-the-fly (work-queue = + consumer-pool-of-size-1)s, which you call "qutexes" and to which jobs can= be submitted via qutex::join().

If anything = like this model were proposed for standardization, I'd hope that it would s= tandardize the underlying (work-queue + consumer-pool-of-size-N) model, so = that you could have constructible-on-the-fly work-queues with consumer-pool= s of size 2 (for example).  Perhaps the atomic concept should even *be= * split up, so that a single consumer-pool could pull from two different wo= rk-queues, etc. etc.

Notice that a work-queue with= only a single producer and/or only a single consumer can be implemented wi= th greater efficiency than a work-queue with multiple producers and/or cons= umers, so there's an efficiency win there that should be reflected in the l= ibrary somehow. However, I don't think the "qutex" concept gets us anywhere= close to where we ought to be in the end.

=E2=80= =93Arthur

On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, t...@ten= tity.com wrote:
Thanks. 
Now I am thinking "qumex" which abbreviation for Qu<= /b>eue of Mutual Exclusion. 
Would it be bette= r?

On Friday, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrot= e:
On Friday, April= 3, 2015 at 5:15:13 AM UTC-7, t...@tentity.com wrote:

Quetex is Mutual Exclusion Queue. It eliminates = blocking/waiting and thread switching in comparison to mutexes and futures.=


=  gpc::quetex<int> qtx;

<= br>
Not related to the semantics, but FYI, "quetex" looks like it= ought to be pronounced "kaytex", and you lose the pun. Consider "queuetex"= or "qutex" instead. :)

=E2=80=93Arthur

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_2297_502619564.1428176355096-- ------=_Part_2296_244332204.1428176355096-- .