Topic: Generic Parallel Computing (GPC) API
Author: tef@tentity.com
Date: Fri, 3 Apr 2015 05:15:13 -0700 (PDT)
Raw View
------=_Part_297_924641526.1428063313015
Content-Type: multipart/alternative;
boundary="----=_Part_298_1258457790.1428063313015"
------=_Part_298_1258457790.1428063313015
Content-Type: text/plain; charset=UTF-8
Now, C++ includes built-in support for threads, mutual exclusion, condition
variables, and futures. But some essential paradigm for parallel computing
is missing.
I am talking about well known *fork/join* but enhanced for task
parallelism.
So, in GPC API:
- the *fork* API does not clone a process or thread but submit a
function/lambda to a thread pool.
- the *join* API submits a function/lambda to a quetex.
Quetex is Mutual Exclusion Queue. It eliminates blocking/waiting and
thread switching in comparison to mutexes and futures.
gpc::quetex<int> qtx;
while( /* condition */ ) {
gpc::fork([qtx]() {
// do something, then
qtx.join([](gpc::mutex<int>& state) {
// exclusive access to <int>
state.setData() or state.getData()
});
});
}
Here is an example of the usage: Reduction
<http://websql.s3-website-us-east-1.amazonaws.com/ReductionCpp.html>
I assume that if C++ includes threads it can include thread pools also. And
if there is mutexes it could be also quetexes there.
I have an implementation of GPC API that I use for my development. You can
try it at http://parallect.codeplex.com
If you have a use case for task parallelization, please share. It would be
interesting to see how the *fork/join* would work or not.
Thanks
Andrew
--
---
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 email 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-proposals/.
------=_Part_298_1258457790.1428063313015
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">
<p class=3D"p1"><span class=3D"s1">Now, C++ includes built-in support for t=
hreads, mutual exclusion, condition variables, and futures. But some essent=
ial paradigm for parallel computing is missing.</span></p><p class=3D"p1">I=
am talking about well known <u>fork/join</u> but enhanced for ta=
sk parallelism. </p><p class=3D"p1">So, in GPC API:</p><p class=3D"p1"=
>
</p><p class=3D"p1"></p><ul><li><span class=3D"s1" style=3D"line-height: 18=
px;">the </span><span class=3D"s2" style=3D"line-height: 18px;"><u>fork</u>=
</span><span class=3D"s1" style=3D"line-height: 18px;"> API does not clone =
a process or thread but submit a function/lambda to a thread pool. </s=
pan><br></li><li><span class=3D"s1" style=3D"line-height: 18px;">the </span=
><span class=3D"s2" style=3D"line-height: 18px;"><u>join</u></span><span cl=
ass=3D"s1" style=3D"line-height: 18px;"> API submits a function/lambda to a=
quetex.</span><br></li></ul><p></p><p class=3D"p1"><span class=3D"s1">
</span></p><p class=3D"p1"><span class=3D"s1">
</span></p><p class=3D"p1"><span class=3D"s1">Quetex is Mutual Exclusion Qu=
eue. I</span>t eliminates blocking/waiting and thread switching in comparis=
on to mutexes and futures.</p><div class=3D"prettyprint" style=3D"border: 1=
px solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(2=
50, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> gpc</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">quetex</span><span styl=
e=3D"color: #080;" class=3D"styled-by-prettify"><int></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> qtx</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br><br> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">while</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">/* condition */</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br> &=
nbsp; gpc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">fork</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">([</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">qtx</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]()</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br><br> </span><s=
pan style=3D"color: #800;" class=3D"styled-by-prettify">// do something, th=
en</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
qtx</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">join</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">([](</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">gpc</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mutex</sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify"><int></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> state</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br> =
</span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// exclusive access to <int></span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br> &nbs=
p; state</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">setD=
ata</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">or</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> state</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify">getData</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">});</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">});</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><p =
class=3D"p1"><span class=3D"s1"><br></span></p><p class=3D"p1">Here is an e=
xample of the usage: <a href=3D"http://websql.s3-website-us-east-1.ama=
zonaws.com/ReductionCpp.html">Reduction</a><br></p><p class=3D"p1">I assume=
that if C++ includes threads it can include thread pools also. And if ther=
e is mutexes it could be also quetexes there.</p><p class=3D"p1">I have an =
implementation of GPC API that I use for my development. You can try it at&=
nbsp;<a href=3D"http://parallect.codeplex.com">http://parallect.codeplex.co=
m</a></p>
<p class=3D"p1">If you have a use case for task parallelization, please sha=
re. It would be interesting to see how the <u>fork/join</u> would=
work or not.</p><p class=3D"p1">Thanks</p><p class=3D"p1">Andrew</p>
<p class=3D"p1"><span class=3D"s1"><br></span></p><p class=3D"p1"><span cla=
ss=3D"s1"><br></span></p></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_298_1258457790.1428063313015--
------=_Part_297_924641526.1428063313015--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Fri, 3 Apr 2015 15:48:48 -0700 (PDT)
Raw View
------=_Part_1301_1290540248.1428101328089
Content-Type: multipart/alternative;
boundary="----=_Part_1302_1571213329.1428101328089"
------=_Part_1302_1571213329.1428101328089
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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<int> qtx;
>
>
Not related to the semantics, but FYI, "quetex" looks like it ought to be=
=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_1302_1571213329.1428101328089
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, April 3, 2015 at 5:15:13 AM UTC-7, t...@tentity=
..com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><p=
></p><p><span>
</span></p><p><span>
</span></p><p><span>Quetex is Mutual Exclusion Queue. I</span>t eliminates =
blocking/waiting and thread switching in comparison to mutexes and futures.=
</p><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:#000"><br>=
gpc</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">quetex</span><span style=3D"color:#080"><int></span><span style=
=3D"color:#000"> qtx</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br><br></span></div></code></div></div></blockquote><div><=
br></div><div>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. :)</div><div><br></div><div>=E2=80=93Arthur</div></div=
>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1302_1571213329.1428101328089--
------=_Part_1301_1290540248.1428101328089--
.
Author: tef@tentity.com
Date: Sat, 4 Apr 2015 07:46:58 -0700 (PDT)
Raw View
------=_Part_1368_1702201582.1428158818932
Content-Type: multipart/alternative;
boundary="----=_Part_1369_124843340.1428158818933"
------=_Part_1369_124843340.1428158818933
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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<int> qtx;
>>
>>
> Not related to the semantics, but FYI, "quetex" looks like it ought to be=
=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_1369_124843340.1428158818933
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks. <div>Now I am thinking "qumex" which abbrevia=
tion for <b>Qu</b>eue of <b>M</b>utual <b>Ex</b>clusion. </div><div>Wo=
uld it be better?<br><br>On Friday, April 3, 2015 at 6:48:48 PM UTC-4, Arth=
ur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Friday, April 3, 2015 at 5:15:13 AM UTC-7, <a>t...@tentity.com</a> w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><p></p><p><sp=
an>
</span></p><p><span>
</span></p><p><span>Quetex is Mutual Exclusion Queue. I</span>t eliminates =
blocking/waiting and thread switching in comparison to mutexes and futures.=
</p><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:#000"><br>=
gpc</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">quetex</span><span style=3D"color:#080"><int></span><span style=
=3D"color:#000"> qtx</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br><br></span></div></code></div></div></blockquote><div><=
br></div><div>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. :)</div><div><br></div><div>=E2=80=93Arthur</div></div=
></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1369_124843340.1428158818933--
------=_Part_1368_1702201582.1428158818932--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sat, 4 Apr 2015 12:39:15 -0700 (PDT)
Raw View
------=_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<int> 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
<div dir=3D"ltr">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<div><br></div><div> (work-queue + c=
onsumer-pool-of-size-N)</div><div><br></div><div>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().</div><div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>=E2=80=
=93Arthur</div><br>On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, t...@ten=
tity.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">Thanks. <div>Now I am thinking "qumex" which abbreviation for <b>Qu<=
/b>eue of <b>M</b>utual <b>Ex</b>clusion. </div><div>Would it be bette=
r?<br><br>On Friday, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, April=
3, 2015 at 5:15:13 AM UTC-7, <a>t...@tentity.com</a> wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><p></p><p><span>
</span></p><p><span>
</span></p><p><span>Quetex is Mutual Exclusion Queue. I</span>t eliminates =
blocking/waiting and thread switching in comparison to mutexes and futures.=
</p><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:#000"><br>=
gpc</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">quetex</span><span style=3D"color:#080"><int></span><span style=
=3D"color:#000"> qtx</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br><br></span></div></code></div></div></blockquote><div><=
br></div><div>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. :)</div><div><br></div><div>=E2=80=93Arthur</div></div=
></blockquote></div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2297_502619564.1428176355096--
------=_Part_2296_244332204.1428176355096--
.
Author: tef@tentity.com
Date: Sat, 4 Apr 2015 16:39:15 -0700 (PDT)
Raw View
------=_Part_1596_717802005.1428190755506
Content-Type: multipart/alternative;
boundary="----=_Part_1597_1682652836.1428190755506"
------=_Part_1597_1682652836.1428190755506
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Let me make some clarification.
In my system, I have one thread pool for everything: forks, joins, http=20
requests, timers, etc.
I avoid creating threads (that is why I do not use std::async) and I avoid=
=20
switching threads.
I don't see any reason to have more than one thread per core (20 years ago=
=20
I would do because it was only one core CPU, but not now).=20
So, I do not create a thread pool per a qutex, but I use one thread pool=20
for everything.=20
Here is the algorithm of the mutual exclusion that is used in the thread=20
pool:
static intptr_t __stdcall Run(tef::sys::THREAD_TASK* task)
{=20
ExclusiveTask* $this =3D static_cast<ExclusiveTask*>(task);=20
auto qutex =3D $this->qutex;=20
if( qutex->Lock() =3D=3D 1 ) {=20
$this->Callback(); // call back the lambda
while( qutex->Unlock() > 0 ) {=20
task =3D qutex->UnsafePop();=20
while( task =3D=3D nullptr ) {=20
task =3D qutex->UnsafePop();=20
}=20
// call back the lambda
ExclusiveTask* t =3D static_cast<ExclusiveTask*>(task);=20
t->Callback();
delete t;
}=20
delete $this;=20
} else {=20
qutex->Push($this);=20
}=20
return 0;=20
}
It is very simple, now, but it wasn't year ago. And it is multiple=20
producer/single consumer queue (non-blocking, based on the atomic increment=
=20
and compare exchange).
I realize that in the standard library thread pool creation would be=20
explicit. Something like:
auto h =3D std:setThreadPoolSize(32);
and/or a thread pool handler could be passed as a parameter to forks and=20
joins also.
However, I don't think the "qutex" concept gets us anywhere close to where=
=20
> we ought to be in the end.
What is the end?=20
I do not see any parallel computational model so far.
Intel TBB Flow Graph or Intel Cnc are awkward. Imagine you have to declare=
=20
a call order of all functions of your program in advance and their call=20
conditions.
So, what is alternative? I have even more advance computational model, but=
=20
it is a way out of the conventional thinking (Method for Automatic Parallel=
=20
Computing <http://www.freepatentsonline.com/y2015/0033242.html>).
By the way, you used 'qutex', not 'qumex'. I am not english native speaker,=
=20
so 'qumex' does not sound right?
Thanks
Andrew
On Saturday, April 4, 2015 at 3:39:15 PM UTC-4, Arthur O'Dwyer wrote:
>
> Now that I've read more of the documentation and have a better idea of th=
e=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 jo=
bs=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 y=
ou=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 wit=
h=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 t=
he=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<int> qtx;
>>>>
>>>>
>>> Not related to the semantics, but FYI, "quetex" looks like it ought to=
=20
>>> be pronounced "kaytex", and you lose the pun. Consider "queuetex" or=20
>>> "qutex" 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_1597_1682652836.1428190755506
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Let me make some clarification.</div><div>In my syste=
m, I have one thread pool for everything: forks, joins, http requests, time=
rs, etc.</div><div>I avoid creating threads (that is why I do not use std::=
async) and I avoid switching threads.</div><div>I don't see any reason to h=
ave more than one thread per core (20 years ago I would do because it was o=
nly one core CPU, but not now). <br></div><div>So, I do not create a t=
hread pool per a qutex, but I use one thread pool for everything. <br>=
</div><div>Here is the algorithm of the mutual exclusion that is used in th=
e thread pool:</div><div><br></div><div>
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">static</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> intptr_t __stdcall </span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Run</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">tef</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">sys</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">THREAD_TASK<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> task</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> <br><br> </span><span style=3D"color: #606=
;" class=3D"styled-by-prettify">ExclusiveTask</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> $this </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">static_cast</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify"><</span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">ExclusiveTask</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">*>(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">task</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br><br>&nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> qutex </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> $this</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">-></span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">qutex</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> <br><br> </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">if</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> qutex</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">-></span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Lock</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">1</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> <br><br> $this</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">-></span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Callback</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pr=
ettify">// call back the lambda</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br><br> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">while</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> qutex</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">-></span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Unlock</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> <br><br> task </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> qutex</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">-></span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">UnsafePop</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> <br><br> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">while</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> task </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">nullptr</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <b=
r><br> task </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> qutex</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">-></span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">UnsafePop</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> <br><br> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> <br></span><span style=3D"color=
: rgb(136, 0, 0);"><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #800;" cla=
ss=3D"styled-by-prettify">// call back the lambda</span></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
ExclusiveTask</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">ExclusiveTask</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*>(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">task</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> <br> t</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">-></span><spa=
n style=3D"color: rgb(102, 0, 102);"><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Callback</span></span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">delete</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> <br><br> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">delete</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> $this</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> <br><br> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">else</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> <br><br> qutex</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">-></span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Push</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">$this</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
br><br> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=
<br> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>return</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> <br><br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div><=
p class=3D"p1"><span class=3D"s2"><br></span></p></div><div>It is very simp=
le, now, but it wasn't year ago. And it is multiple producer/single consume=
r queue (non-blocking, based on the atomic increment and compare exchange).=
</div><div><br></div><div>I realize that in the standard library thread poo=
l creation would be explicit. Something like:</div><div><br></div><div><div=
class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-=
wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pre=
ttyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> h </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">setThreadPo=
olSize</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #066;" class=3D"styled-by-prettify">32</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code=
></div><br></div><div>and/or a thread pool handler could be passed as a par=
ameter to forks and joins also.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; bord=
er-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: =
1ex;">However, I don't think the "qutex" concept gets us anywhere close to =
where we ought to be in the end.</blockquote><div><br></div><div>What is th=
e end? </div><div><br></div><div>I do not see any parallel computation=
al model so far.</div><div>Intel TBB Flow Graph or Intel Cnc are awkward. I=
magine you have to declare a call order of all functions of your program in=
advance and their call conditions.</div><div>So, what is alternative? I ha=
ve even more advance computational model, but it is a way out of the conven=
tional thinking (<a href=3D"http://www.freepatentsonline.com/y2015/0033242.=
html">Method for Automatic Parallel Computing</a>).</div><div><br></div><di=
v>By the way, you used 'qutex', not 'qumex'. I am not english native speake=
r, so 'qumex' does not sound right?</div><div><br></div><div>Thanks</div><d=
iv>Andrew</div><br>On Saturday, April 4, 2015 at 3:39:15 PM UTC-4, Arthur O=
'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
Now that I've read more of the documentation and have a better idea of the =
concepts involved... If I understand correctly, you start from the atomic c=
oncept of<div><br></div><div> (work-queue + consumer-pool-of-s=
ize-N)</div><div><br></div><div>In your particular system there is a single=
ton global (work-queue + consumer-pool-of-size-LARGE) that you call "the th=
read pool", to which jobs can be submitted via gpc::fork(); and your =
system also supports constructible-on-the-fly (work-queue + consumer-pool-o=
f-size-1)s, which you call "qutexes" and to which jobs can be submitted via=
qutex::join().</div><div><div><br></div><div>If anything like this model w=
ere proposed for standardization, I'd hope that it would standardize the un=
derlying (work-queue + consumer-pool-of-size-N) model, so that you could ha=
ve constructible-on-the-fly work-queues with consumer-pools of size 2 (for =
example). Perhaps the atomic concept should even *be* split up, so th=
at a single consumer-pool could pull from two different work-queues, etc. e=
tc.</div><div><br></div><div>Notice that a work-queue with only a single pr=
oducer and/or only a single consumer can be implemented with greater effici=
ency than a work-queue with multiple producers and/or consumers, so there's=
an efficiency win there that should be reflected in the library somehow. H=
owever, I don't think the "qutex" concept gets us anywhere close to where w=
e ought to be in the end.</div><div><br></div><div>=E2=80=93Arthur</div><br=
>On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, <a>t...@tentity.com</a> wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thanks. <=
div>Now I am thinking "qumex" which abbreviation for <b>Qu</b>eue of <b>M</=
b>utual <b>Ex</b>clusion. </div><div>Would it be better?<br><br>On Fri=
day, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr">On Friday, April 3, 2015 at 5:15=
:13 AM UTC-7, <a>t...@tentity.com</a> wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><p></p><p><span>
</span></p><p><span>
</span></p><p><span>Quetex is Mutual Exclusion Queue. I</span>t eliminates =
blocking/waiting and thread switching in comparison to mutexes and futures.=
</p><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:#000"><br>=
gpc</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">quetex</span><span style=3D"color:#080"><int></span><span style=
=3D"color:#000"> qtx</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br><br></span></div></code></div></div></blockquote><div><=
br></div><div>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. :)</div><div><br></div><div>=E2=80=93Arthur</div></div=
></blockquote></div></div></blockquote></div></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1597_1682652836.1428190755506--
------=_Part_1596_717802005.1428190755506--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 06 Apr 2015 11:19:24 -0400
Raw View
On 2015-04-04 10:46, tef@tentity.com wrote:
> Thanks.
> Now I am thinking "qumex" which abbreviation for *Qu*eue of *M*utual *Ex*
> clusion.
> Would it be better?
"[Thread safe] queue" :-).
--
Matthew
--
---
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 email 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-proposals/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Mon, 6 Apr 2015 22:49:48 +0200
Raw View
--089e013c63745bf3e60513147028
Content-Type: text/plain; charset=UTF-8
It indeed looks a lot like a thread-safe queue or a "strand" (a task
executor which guarantee that tasks are not executed
concurrently but asap in order).
On Mon, Apr 6, 2015 at 5:19 PM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2015-04-04 10:46, tef@tentity.com wrote:
> > Thanks.
> > Now I am thinking "qumex" which abbreviation for *Qu*eue of *M*utual *Ex*
> > clusion.
> > Would it be better?
>
> "[Thread safe] queue" :-).
>
> --
> Matthew
>
> --
>
> ---
> 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
> email 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-proposals/.
>
--
---
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 email 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-proposals/.
--089e013c63745bf3e60513147028
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It indeed looks a lot like a thread-safe queue or a "=
strand" (a task executor which guarantee that tasks are not executed<d=
iv>concurrently but asap in order).<div><br></div></div></div><div class=3D=
"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Apr 6, 2015 at 5:19 PM=
, Matthew Woehlke <span dir=3D"ltr"><<a href=3D"mailto:mw_triad@users.so=
urceforge.net" target=3D"_blank">mw_triad@users.sourceforge.net</a>></sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2015-04-04=
10:46, <a href=3D"mailto:tef@tentity.com">tef@tentity.com</a> wrote:<br>
> Thanks.<br>
</span>> Now I am thinking "qumex" which abbreviation for *Qu*=
eue of *M*utual *Ex*<br>
> clusion.<br>
> Would it be better?<br>
<br>
"[Thread safe] queue" :-).<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013c63745bf3e60513147028--
.
Author: tef@tentity.com
Date: Mon, 6 Apr 2015 19:33:42 -0700 (PDT)
Raw View
------=_Part_1455_1701014568.1428374022704
Content-Type: multipart/alternative;
boundary="----=_Part_1456_1649535512.1428374022704"
------=_Part_1456_1649535512.1428374022704
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Yes, indeed. It says "Quetex is Mutual Exclusion Queue", where
Mutual Exclusion means tasks are not executed concurrently,
and Queue means* a queue. *You got it.
Actually, the proposal is about parallel computing and *fork/join* as basic=
=20
constructs of task parallelism.=20
I use a queue, but probably you know a better data structure that fit there=
..
And by the way, it is only thread safe for the producer.
On Monday, April 6, 2015 at 4:49:50 PM UTC-4, Klaim - Jo=C3=ABl Lamotte wro=
te:
>
> It indeed looks a lot like a thread-safe queue or a "strand" (a task=20
> executor which guarantee that tasks are not executed
> concurrently but asap in order).
>
>
> On Mon, Apr 6, 2015 at 5:19 PM, Matthew Woehlke <
> mw_t...@users.sourceforge.net <javascript:>> wrote:
>
>> On 2015-04-04 10:46, t...@tentity.com <javascript:> wrote:
>> > Thanks.
>> > Now I am thinking "qumex" which abbreviation for *Qu*eue of *M*utual=
=20
>> *Ex*
>> > clusion.
>> > Would it be better?
>>
>> "[Thread safe] queue" :-).
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>
--=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_1456_1649535512.1428374022704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Yes, indeed. It says "Quetex is Mutual Exclusion Queue", w=
here<div>Mutual Exclusion means tasks are not executed concurrently,</=
div><div>and Queue means<b> a queue. </b>You got it.</div><div><b><br></b><=
/div><div>Actually, the proposal is about parallel computing and =
<u>fork/join</u> as basic constructs of task parallelism. </div><=
div>I use a queue, but probably you know a better data structure that fit t=
here.</div><div>And by the way, it is only thread safe for the producer.</d=
iv><div><br></div><div><br>On Monday, April 6, 2015 at 4:49:50 PM UTC-4, Kl=
aim - Jo=C3=ABl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr">It indeed looks a lot like a thread-safe queue or a "stran=
d" (a task executor which guarantee that tasks are not executed<div>concurr=
ently but asap in order).<div><br></div></div></div><div><br><div class=3D"=
gmail_quote">On Mon, Apr 6, 2015 at 5:19 PM, Matthew Woehlke <span dir=3D"l=
tr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
uW4MFb9i_EoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">mw_t...@users=
..sourceforge.<wbr>net</a>></span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><span>On 2015-04-04 10:46, <a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"uW4MFb9i_EoJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retur=
n true;">t...@tentity.com</a> wrote:<br>
> Thanks.<br>
</span>> Now I am thinking "qumex" which abbreviation for *Qu*eue of *M*=
utual *Ex*<br>
> clusion.<br>
> Would it be better?<br>
<br>
"[Thread safe] queue" :-).<br>
<span><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div><div><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
uW4MFb9i_EoJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal.=
...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"uW4MFb9i_EoJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:=
';return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';return true=
;" onclick=3D"this.href=3D'http://groups.google.com/a/isocpp.org/group/std-=
proposals/';return true;">http://groups.google.com/a/<wbr>isocpp.org/group/=
std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1456_1649535512.1428374022704--
------=_Part_1455_1701014568.1428374022704--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Tue, 7 Apr 2015 11:19:59 +0200
Raw View
--089e013c63743253f005131eeb31
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm not a specialist. Although I remember several proposals
specifying algorithms and objects to do fork/join.
I thought that some of these were added in the recent parallel algorithm TS
but I cahn't find them there.
On Tue, Apr 7, 2015 at 4:33 AM, <tef@tentity.com> wrote:
> Yes, indeed. It says "Quetex is Mutual Exclusion Queue", where
> Mutual Exclusion means tasks are not executed concurrently,
> and Queue means* a queue. *You got it.
>
> Actually, the proposal is about parallel computing and *fork/join* as
> basic constructs of task parallelism.
> I use a queue, but probably you know a better data structure that fit
> there.
> And by the way, it is only thread safe for the producer.
>
>
> On Monday, April 6, 2015 at 4:49:50 PM UTC-4, Klaim - Jo=C3=ABl Lamotte w=
rote:
>>
>> It indeed looks a lot like a thread-safe queue or a "strand" (a task
>> executor which guarantee that tasks are not executed
>> concurrently but asap in order).
>>
>>
>> On Mon, Apr 6, 2015 at 5:19 PM, Matthew Woehlke <
>> mw_t...@users.sourceforge.net> wrote:
>>
>>> On 2015-04-04 10:46, t...@tentity.com wrote:
>>> > Thanks.
>>> > Now I am thinking "qumex" which abbreviation for *Qu*eue of *M*utual
>>> *Ex*
>>> > clusion.
>>> > Would it be better?
>>>
>>> "[Thread safe] queue" :-).
>>>
>>> --
>>> Matthew
>>>
>>> --
>>>
>>> ---
>>> 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 email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>> proposals/.
>>>
>>
>> --
>
> ---
> 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
> email 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-proposals/.
>
--=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/.
--089e013c63743253f005131eeb31
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm not a specialist. Although I remember several prop=
osals=C2=A0<div>specifying algorithms and objects to do fork/join.</div><di=
v>I thought that some of these were added in the recent parallel algorithm =
TS</div><div>but I cahn't find them there.</div></div><div class=3D"gma=
il_extra"><br><div class=3D"gmail_quote">On Tue, Apr 7, 2015 at 4:33 AM, <=
span dir=3D"ltr"><<a href=3D"mailto:tef@tentity.com" target=3D"_blank">t=
ef@tentity.com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr">Yes, indeed. It says "Quetex is Mutual Exclusion Queue&qu=
ot;, where<div>Mutual Exclusion means=C2=A0tasks are not executed concurren=
tly,</div><div>and Queue means<b> a queue. </b>You got it.</div><div><b><br=
></b></div><div>Actually, the proposal is about=C2=A0parallel computing and=
=C2=A0<u>fork/join</u>=C2=A0as basic constructs of task parallelism.=C2=A0<=
/div><div>I use a queue, but probably you know a better data structure that=
fit there.</div><div>And by the way, it is only thread safe for the produc=
er.</div><div><br></div><div><span class=3D""><br>On Monday, April 6, 2015 =
at 4:49:50 PM UTC-4, Klaim - Jo=C3=ABl Lamotte wrote:</span><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr">It indeed looks =
a lot like a thread-safe queue or a "strand" (a task executor whi=
ch guarantee that tasks are not executed<div>concurrently but asap in order=
).<div><br></div></div></div></span><div><br><div class=3D"gmail_quote">On =
Mon, Apr 6, 2015 at 5:19 PM, Matthew Woehlke <span dir=3D"ltr"><<a rel=
=3D"nofollow">mw_t...@users.sourceforge.<u></u>net</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><span class=3D""><span>On 2015-04-04 10:46,=
<a rel=3D"nofollow">t...@tentity.com</a> wrote:<br>
> Thanks.<br>
</span>> Now I am thinking "qumex" which abbreviation for *Qu*=
eue of *M*utual *Ex*<br>
> clusion.<br>
> Would it be better?<br>
<br>
"[Thread safe] queue" :-).<br>
<span><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span></span><div><div><span class=3D""><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/<u></u>isocpp.org/group/std-<u></u>proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013c63743253f005131eeb31--
.
Author: Zijie He <hzj_jie@hotmail.com>
Date: Fri, 10 Apr 2015 08:03:27 -0700 (PDT)
Raw View
------=_Part_1195_964796084.1428678207536
Content-Type: multipart/alternative;
boundary="----=_Part_1196_1826248938.1428678207536"
------=_Part_1196_1826248938.1428678207536
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Single consumer queue is not good for modern hardware, at least we need to=
=20
have one thread i.e. one consumer per core.
For the parallel computational model, I was working on .Net before, and was=
=20
using lambda expressions to define the order of steps,
imaging,
auto x =3D define_a_procedure(
[]() {
.... do some processor work ...
waitfor(an_io_or_lock); // the lock here is not the common lock
goto_next_step();
},
[]() {
.... obtained the lock or io operation finished ...
.... do some processor work ...
goto_finish();
});
run(x); // non-blocking
And each step may work on different threads, the whole procedure will not=
=20
stop until goto_finish() involved.
But when porting to c++, issues as the lifetime of the procedure, it should=
=20
keep alive until goto_finish(), and meanwhile, the most important thing is,=
=20
if we need to refer some local variables <which is the reason to use lambda=
=20
expressions>, we also need to consider the lifetime of these variables. I=
=20
tried to use shared_ptr everywhere, but still have some trouble.
On Sunday, April 5, 2015 at 7:39:15 AM UTC+8, t...@tentity.com wrote:
>
> Let me make some clarification.
> In my system, I have one thread pool for everything: forks, joins, http=
=20
> requests, timers, etc.
> I avoid creating threads (that is why I do not use std::async) and I avoi=
d=20
> switching threads.
> I don't see any reason to have more than one thread per core (20 years ag=
o=20
> I would do because it was only one core CPU, but not now).=20
> So, I do not create a thread pool per a qutex, but I use one thread pool=
=20
> for everything.=20
> Here is the algorithm of the mutual exclusion that is used in the thread=
=20
> pool:
>
> static intptr_t __stdcall Run(tef::sys::THREAD_TASK* task)
> {=20
>
> ExclusiveTask* $this =3D static_cast<ExclusiveTask*>(task);=20
>
> auto qutex =3D $this->qutex;=20
>
> if( qutex->Lock() =3D=3D 1 ) {=20
>
> $this->Callback(); // call back the lambda
>
> while( qutex->Unlock() > 0 ) {=20
>
> task =3D qutex->UnsafePop();=20
>
> while( task =3D=3D nullptr ) {=20
>
> task =3D qutex->UnsafePop();=20
>
> }=20
> // call back the lambda
> ExclusiveTask* t =3D static_cast<ExclusiveTask*>(task);=20
> t->Callback();
> delete t;
>
> }=20
>
> delete $this;=20
>
> } else {=20
>
> qutex->Push($this);=20
>
> }=20
>
> return 0;=20
>
> }
>
>
> It is very simple, now, but it wasn't year ago. And it is multiple=20
> producer/single consumer queue (non-blocking, based on the atomic increme=
nt=20
> and compare exchange).
>
> I realize that in the standard library thread pool creation would be=20
> explicit. Something like:
>
> auto h =3D std:setThreadPoolSize(32);
>
> and/or a thread pool handler could be passed as a parameter to forks and=
=20
> joins also.
>
> However, I don't think the "qutex" concept gets us anywhere close to wher=
e=20
>> we ought to be in the end.
>
>
> What is the end?=20
>
> I do not see any parallel computational model so far.
> Intel TBB Flow Graph or Intel Cnc are awkward. Imagine you have to declar=
e=20
> a call order of all functions of your program in advance and their call=
=20
> conditions.
> So, what is alternative? I have even more advance computational model, bu=
t=20
> it is a way out of the conventional thinking (Method for Automatic=20
> Parallel Computing <http://www.freepatentsonline.com/y2015/0033242.html>)=
..
>
> By the way, you used 'qutex', not 'qumex'. I am not english native=20
> speaker, so 'qumex' does not sound right?
>
> Thanks
> Andrew
>
> On Saturday, April 4, 2015 at 3:39:15 PM UTC-4, Arthur O'Dwyer wrote:
>>
>> Now that I've read more of the documentation and have a better idea of=
=20
>> the concepts involved... If I understand correctly, you start from the=
=20
>> atomic 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 j=
obs=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 singl=
e=20
>> consumer can be implemented with greater efficiency than a work-queue wi=
th=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 en=
d.
>>
>> =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=20
>>> *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<int> qtx;
>>>>>
>>>>>
>>>> Not related to the semantics, but FYI, "quetex" looks like it ought to=
=20
>>>> be pronounced "kaytex", and you lose the pun. Consider "queuetex" or=
=20
>>>> "qutex" 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_1196_1826248938.1428678207536
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Single consumer queue is not good for modern hardware, at =
least we need to have one thread i.e. one consumer per core.<br><br>For the=
parallel computational model, I was working on .Net before, and was using =
lambda expressions to define the order of steps,<div>imaging,</div><div><br=
></div><div>auto x =3D define_a_procedure(</div><div>[]() {</div><div>... d=
o some processor work ...</div><div>waitfor(an_io_or_lock); // the lock her=
e is not the common lock</div><div>goto_next_step();<br>},</div><div>[]() {=
</div><div>... obtained the lock or io operation finished ...</div><div>...=
do some processor work ...</div><div>goto_finish();<br>});</div><div>run(x=
); // non-blocking</div><div>And each step may work on different threads, t=
he whole procedure will not stop until goto_finish() involved.</div><div>Bu=
t when porting to c++, issues as the lifetime of the procedure, it should k=
eep alive until goto_finish(), and meanwhile, the most important thing is, =
if we need to refer some local variables <which is the reason to use lam=
bda expressions>, we also need to consider the lifetime of these variabl=
es. I tried to use shared_ptr everywhere, but still have some trouble.</div=
><div><br>On Sunday, April 5, 2015 at 7:39:15 AM UTC+8, t...@tentity.com wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Let =
me make some clarification.</div><div>In my system, I have one thread pool =
for everything: forks, joins, http requests, timers, etc.</div><div>I avoid=
creating threads (that is why I do not use std::async) and I avoid switchi=
ng threads.</div><div>I don't see any reason to have more than one thread p=
er core (20 years ago I would do because it was only one core CPU, but not =
now). <br></div><div>So, I do not create a thread pool per a qutex, bu=
t I use one thread pool for everything. <br></div><div>Here is the alg=
orithm of the mutual exclusion that is used in the thread pool:</div><div><=
br></div><div>
<div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgr=
ound-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">static</=
span><span style=3D"color:#000"> intptr_t __stdcall </span><span style=3D"c=
olor:#606">Run</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">tef</span><span style=3D"color:#660">::</span><span style=3D"color:=
#000">sys</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">THREAD_TASK</span><span style=3D"color:#660">*</span><span style=3D"col=
or:#000"> task</span><span style=3D"color:#660">)</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"color:=
#000"> <br><br> </span><span style=3D"color:#606">ExclusiveTask</span=
><span style=3D"color:#660">*</span><span style=3D"color:#000"> $this </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">static_cast</span><span style=3D"color:#660"><=
</span><span style=3D"color:#606">ExclusiveTask</span><span style=3D"color:=
#660">*>(</span><span style=3D"color:#000">ta<wbr>sk</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"> <br><br> </span>=
<span style=3D"color:#008">auto</span><span style=3D"color:#000"> qutex </s=
pan><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> $this<=
/span><span style=3D"color:#660">-></span><span style=3D"color:#000">qut=
ex</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> <br=
><br> </span><span style=3D"color:#008">if</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000"> qutex</span><span style=3D"color=
:#660">-></span><span style=3D"color:#606">Lock</span><span style=3D"col=
or:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">=3D=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#=
066">1</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"> <br><br> $this</span><sp=
an style=3D"color:#660">-></span><span style=3D"color:#606">Callback</sp=
an><span style=3D"color:#660">();</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#800">// call back the lambda</span><span style=3D"col=
or:#000"><br><br> </span><span style=3D"color:#008">whi=
le</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> qut=
ex</span><span style=3D"color:#660">-></span><span style=3D"color:#606">=
Unlock</span><span style=3D"color:#660">()</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">></span><span style=3D"color:#000"> =
</span><span style=3D"color:#066">0</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"> <br><br> =
task </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> qutex</span><span style=3D"color:#660">-></=
span><span style=3D"color:#606">UnsafePop</span><span style=3D"color:#660">=
();</span><span style=3D"color:#000"> <br><br> &=
nbsp;</span><span style=3D"color:#008">while</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#000"> task </span><span style=3D"color:#66=
0">=3D=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">nullptr</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"> <br><br> &nbs=
p; task </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> qutex</span><span style=3D"color:#660">-></span><span style=
=3D"color:#606">UnsafePop</span><span style=3D"color:#660">();</span><span =
style=3D"color:#000"> <br><br> </span><spa=
n style=3D"color:#660">}</span><span style=3D"color:#000"> <br></span><span=
style=3D"color:rgb(136,0,0)"><span style=3D"color:#000"> &nbs=
p; </span><span style=3D"color:#800">// call back the lambda</=
span></span><span style=3D"color:#000"><br> &nbs=
p;</span><span style=3D"color:#606">ExclusiveTask</span><span style=3D"colo=
r:#660">*</span><span style=3D"color:#000"> t </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">static_cast</span><span style=3D"color:#660"><</span><span style=3D"co=
lor:#606">ExclusiveTask</span><span style=3D"color:#660">*>(</span><span=
style=3D"color:#000">ta<wbr>sk</span><span style=3D"color:#660">);</span><=
span style=3D"color:#000"> <br> t</span><s=
pan style=3D"color:#660">-></span><span style=3D"color:rgb(102,0,102)"><=
span style=3D"color:#606">Callback</span></span><span style=3D"color:#660">=
();</span><span style=3D"color:#000"><br> =
</span><span style=3D"color:#008">delete</span><span style=3D"color:#000"> =
t</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><=
br> </span><span style=3D"color:#660">}</span><span sty=
le=3D"color:#000"> <br><br> </span><span style=3D"color=
:#008">delete</span><span style=3D"color:#000"> $this</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> <br><br> </span><span=
style=3D"color:#660">}</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">else</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> <br><br> &=
nbsp; qutex</span><span style=3D"color:#660">-></span><span style=3D"col=
or:#606">Push</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">$this</span><span style=3D"color:#660">);</span><span style=3D"color=
:#000"> <br><br> </span><span style=3D"color:#660">}</span><span styl=
e=3D"color:#000"> <br><br> </span><span style=3D"color:#008">return</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span>=
<span style=3D"color:#660">;</span><span style=3D"color:#000"> <br><br></sp=
an><span style=3D"color:#660">}</span></div></code></div><p><span><br></spa=
n></p></div><div>It is very simple, now, but it wasn't year ago. And it is =
multiple producer/single consumer queue (non-blocking, based on the atomic =
increment and compare exchange).</div><div><br></div><div>I realize that in=
the standard library thread pool creation would be explicit. Something lik=
e:</div><div><br></div><div><div style=3D"border:1px solid rgb(187,187,187)=
;word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span s=
tyle=3D"color:#008">auto</span><span style=3D"color:#000"> h </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> std</span><span s=
tyle=3D"color:#660">:</span><span style=3D"color:#000">setThreadPoolSize</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#066">32</span>=
<span style=3D"color:#660">);</span></div></code></div><br></div><div>and/o=
r a thread pool handler could be passed as a parameter to forks and joins a=
lso.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">However, I don't think the "qutex=
" concept gets us anywhere close to where we ought to be in the end.</block=
quote><div><br></div><div>What is the end? </div><div><br></div><div>I=
do not see any parallel computational model so far.</div><div>Intel TBB Fl=
ow Graph or Intel Cnc are awkward. Imagine you have to declare a call order=
of all functions of your program in advance and their call conditions.</di=
v><div>So, what is alternative? I have even more advance computational mode=
l, but it is a way out of the conventional thinking (<a href=3D"http://www.=
freepatentsonline.com/y2015/0033242.html" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fww=
w.freepatentsonline.com%2Fy2015%2F0033242.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEQIQ4OpC7iDRbw1Xt0MyW4EI2v9Q';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.freepatentsonline.com%2Fy201=
5%2F0033242.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEQIQ4OpC7iDRbw1Xt0MyW4E=
I2v9Q';return true;">Method for Automatic Parallel Computing</a>).</div><di=
v><br></div><div>By the way, you used 'qutex', not 'qumex'. I am not englis=
h native speaker, so 'qumex' does not sound right?</div><div><br></div><div=
>Thanks</div><div>Andrew</div><br>On Saturday, April 4, 2015 at 3:39:15 PM =
UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Now that I've read more of the documentation and have a better id=
ea of the concepts involved... If I understand correctly, you start from th=
e atomic concept of<div><br></div><div> (work-queue + consumer=
-pool-of-size-N)</div><div><br></div><div>In your particular system there i=
s a singleton global (work-queue + consumer-pool-of-size-LARGE) that you ca=
ll "the thread pool", to which jobs can be submitted via gpc::fork();  =
;and your system also supports constructible-on-the-fly (work-queue + consu=
mer-pool-of-size-1)s, which you call "qutexes" and to which jobs can be sub=
mitted via qutex::join().</div><div><div><br></div><div>If anything like th=
is model were proposed for standardization, I'd hope that it would standard=
ize the underlying (work-queue + consumer-pool-of-size-N) model, so that yo=
u could have constructible-on-the-fly work-queues with consumer-pools of si=
ze 2 (for example). Perhaps the atomic concept should even *be* split=
up, so that a single consumer-pool could pull from two different work-queu=
es, etc. etc.</div><div><br></div><div>Notice that a work-queue with only a=
single producer and/or only a single consumer can be implemented with grea=
ter efficiency than a work-queue with multiple producers and/or consumers, =
so there's an efficiency win there that should be reflected in the library =
somehow. However, I don't think the "qutex" concept gets us anywhere close =
to where we ought to be in the end.</div><div><br></div><div>=E2=80=93Arthu=
r</div><br>On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, <a>t...@tentity.=
com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Than=
ks. <div>Now I am thinking "qumex" which abbreviation for <b>Qu</b>eue=
of <b>M</b>utual <b>Ex</b>clusion. </div><div>Would it be better?<br>=
<br>On Friday, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, April 3, 20=
15 at 5:15:13 AM UTC-7, <a>t...@tentity.com</a> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><p></p><p><span>
</span></p><p><span>
</span></p><p><span>Quetex is Mutual Exclusion Queue. I</span>t eliminates =
blocking/waiting and thread switching in comparison to mutexes and futures.=
</p><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:#000"><br>=
gpc</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">quetex</span><span style=3D"color:#080"><int></span><span style=
=3D"color:#000"> qtx</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br><br></span></div></code></div></div></blockquote><div><=
br></div><div>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. :)</div><div><br></div><div>=E2=80=93Arthur</div></div=
></blockquote></div></div></blockquote></div></div></blockquote></div></blo=
ckquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1196_1826248938.1428678207536--
------=_Part_1195_964796084.1428678207536--
.
Author: tef@tentity.com
Date: Fri, 10 Apr 2015 11:06:59 -0700 (PDT)
Raw View
------=_Part_751_1543097202.1428689219953
Content-Type: multipart/alternative;
boundary="----=_Part_752_1822152842.1428689219954"
------=_Part_752_1822152842.1428689219954
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
It seems you assume that a single consumer queue can be only processed by=
=20
one thread.=20
Actually, it depends on an implementation.
In my implementation, at any moment of time only one thread can process a=
=20
queue (that is mutual exclusion),
but at different times different threads can process the same queue.
And because a system can have a lot of single consumer queues,=20
it also take care of tasks' fair ordering.
In some cases, it is good for modern hardware to process tasks from the=20
same queue on the same core.
Because the purpose of the mutual exclusion is to serialize access to some=
=20
data.
After the first task, the data will be in CPU cache, so next tasks do not=
=20
have to fetch the data from the main memory.
My algorithm is friendly for CPU caches and NUMA optimization.=20
And it is a working system. I use it for 2 years already.
I just recently integrated it with V8, so I can do parallel computing with=
=20
JavaScript now.
On Friday, April 10, 2015 at 11:03:27 AM UTC-4, Zijie He wrote:
>
> Single consumer queue is not good for modern hardware, at least we need t=
o=20
> have one thread i.e. one consumer per core.
>
> For the parallel computational model, I was working on .Net before, and=
=20
> was using lambda expressions to define the order of steps,
> imaging,
>
> auto x =3D define_a_procedure(
> []() {
> ... do some processor work ...
> waitfor(an_io_or_lock); // the lock here is not the common lock
> goto_next_step();
> },
> []() {
> ... obtained the lock or io operation finished ...
> ... do some processor work ...
> goto_finish();
> });
> run(x); // non-blocking
> And each step may work on different threads, the whole procedure will not=
=20
> stop until goto_finish() involved.
> But when porting to c++, issues as the lifetime of the procedure, it=20
> should keep alive until goto_finish(), and meanwhile, the most important=
=20
> thing is, if we need to refer some local variables <which is the reason t=
o=20
> use lambda expressions>, we also need to consider the lifetime of these=
=20
> variables. I tried to use shared_ptr everywhere, but still have some=20
> trouble.
>
> On Sunday, April 5, 2015 at 7:39:15 AM UTC+8, t...@tentity.com wrote:
>>
>> Let me make some clarification.
>> In my system, I have one thread pool for everything: forks, joins, http=
=20
>> requests, timers, etc.
>> I avoid creating threads (that is why I do not use std::async) and I=20
>> avoid switching threads.
>> I don't see any reason to have more than one thread per core (20 years=
=20
>> ago I would do because it was only one core CPU, but not now).=20
>> So, I do not create a thread pool per a qutex, but I use one thread pool=
=20
>> for everything.=20
>> Here is the algorithm of the mutual exclusion that is used in the thread=
=20
>> pool:
>>
>> static intptr_t __stdcall Run(tef::sys::THREAD_TASK* task)
>> {=20
>>
>> ExclusiveTask* $this =3D static_cast<ExclusiveTask*>(task);=20
>>
>> auto qutex =3D $this->qutex;=20
>>
>> if( qutex->Lock() =3D=3D 1 ) {=20
>>
>> $this->Callback(); // call back the lambda
>>
>> while( qutex->Unlock() > 0 ) {=20
>>
>> task =3D qutex->UnsafePop();=20
>>
>> while( task =3D=3D nullptr ) {=20
>>
>> task =3D qutex->UnsafePop();=20
>>
>> }=20
>> // call back the lambda
>> ExclusiveTask* t =3D static_cast<ExclusiveTask*>(task);=20
>> t->Callback();
>> delete t;
>>
>> }=20
>>
>> delete $this;=20
>>
>> } else {=20
>>
>> qutex->Push($this);=20
>>
>> }=20
>>
>> return 0;=20
>>
>> }
>>
>>
>> It is very simple, now, but it wasn't year ago. And it is multiple=20
>> producer/single consumer queue (non-blocking, based on the atomic increm=
ent=20
>> and compare exchange).
>>
>> I realize that in the standard library thread pool creation would be=20
>> explicit. Something like:
>>
>> auto h =3D std:setThreadPoolSize(32);
>>
>> and/or a thread pool handler could be passed as a parameter to forks and=
=20
>> joins also.
>>
>> However, I don't think the "qutex" concept gets us anywhere close to=20
>>> where we ought to be in the end.
>>
>>
>> What is the end?=20
>>
>> I do not see any parallel computational model so far.
>> Intel TBB Flow Graph or Intel Cnc are awkward. Imagine you have to=20
>> declare a call order of all functions of your program in advance and the=
ir=20
>> call conditions.
>> So, what is alternative? I have even more advance computational model,=
=20
>> but it is a way out of the conventional thinking (Method for Automatic=
=20
>> Parallel Computing <http://www.freepatentsonline.com/y2015/0033242.html>
>> ).
>>
>> By the way, you used 'qutex', not 'qumex'. I am not english native=20
>> speaker, so 'qumex' does not sound right?
>>
>> Thanks
>> Andrew
>>
>> On Saturday, April 4, 2015 at 3:39:15 PM UTC-4, Arthur O'Dwyer wrote:
>>>
>>> Now that I've read more of the documentation and have a better idea of=
=20
>>> the concepts involved... If I understand correctly, you start from the=
=20
>>> atomic 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 tha=
t a=20
>>> single consumer-pool could pull from two different work-queues, etc. et=
c.
>>>
>>> Notice that a work-queue with only a single producer and/or only a=20
>>> single consumer can be implemented with greater efficiency than a=20
>>> work-queue with multiple producers and/or consumers, so there's an=20
>>> efficiency win there that should be reflected in the library somehow.=
=20
>>> However, I don't think the "qutex" concept gets us anywhere close to wh=
ere=20
>>> 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=
=20
>>>> *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=20
>>>>>> and thread switching in comparison to mutexes and futures.
>>>>>>
>>>>>> gpc::quetex<int> qtx;
>>>>>>
>>>>>>
>>>>> Not related to the semantics, but FYI, "quetex" looks like it ought t=
o=20
>>>>> be pronounced "kaytex", and you lose the pun. Consider "queuetex" or=
=20
>>>>> "qutex" 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_752_1822152842.1428689219954
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It seems you assume that a single consumer queue can be on=
ly processed by one thread. <br><div>Actually, it depends on an implem=
entation.</div><div>In my implementation, at any moment of time only o=
ne thread can process a queue (that is mutual exclusion),</div><div>but at =
different times different threads can process the same queue.</di=
v><div>And because a system can have a lot of single consumer queues, =
</div><div>it also take care of tasks' fair ordering.</div><div><br></div><=
div>In some cases, it is good for modern hardware to process tasks from the=
same queue on the same core.</div><div>Because the purpose of the mutual e=
xclusion is to serialize access to some data.</div><div>After the first tas=
k, the data will be in CPU cache, so next tasks do not have to fetch the da=
ta from the main memory.</div><div><br></div><div>My algorithm is friendly =
for CPU caches and NUMA optimization. </div><div>And it is a working s=
ystem. I use it for 2 years already.<div>I just recently integrated it with=
V8, so I can do parallel computing with JavaScript now.</div><div><br><br>=
On Friday, April 10, 2015 at 11:03:27 AM UTC-4, Zijie He wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Single consumer queue is =
not good for modern hardware, at least we need to have one thread i.e. one =
consumer per core.<br><br>For the parallel computational model, I was worki=
ng on .Net before, and was using lambda expressions to define the order of =
steps,<div>imaging,</div><div><br></div><div>auto x =3D define_a_procedure(=
</div><div>[]() {</div><div>... do some processor work ...</div><div>waitfo=
r(an_io_or_lock); // the lock here is not the common lock</div><div>goto_ne=
xt_step();<br>},</div><div>[]() {</div><div>... obtained the lock or io ope=
ration finished ...</div><div>... do some processor work ...</div><div>goto=
_finish();<br>});</div><div>run(x); // non-blocking</div><div>And each step=
may work on different threads, the whole procedure will not stop until got=
o_finish() involved.</div><div>But when porting to c++, issues as the lifet=
ime of the procedure, it should keep alive until goto_finish(), and meanwhi=
le, the most important thing is, if we need to refer some local variables &=
lt;which is the reason to use lambda expressions>, we also need to consi=
der the lifetime of these variables. I tried to use shared_ptr everywhere, =
but still have some trouble.</div><div><br>On Sunday, April 5, 2015 at 7:39=
:15 AM UTC+8, <a>t...@tentity.com</a> wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>Let me make some clarification.</div><div>In=
my system, I have one thread pool for everything: forks, joins, http reque=
sts, timers, etc.</div><div>I avoid creating threads (that is why I do not =
use std::async) and I avoid switching threads.</div><div>I don't see any re=
ason to have more than one thread per core (20 years ago I would do because=
it was only one core CPU, but not now). <br></div><div>So, I do not c=
reate a thread pool per a qutex, but I use one thread pool for everything.&=
nbsp;<br></div><div>Here is the algorithm of the mutual exclusion that is u=
sed in the thread pool:</div><div><br></div><div>
<div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgr=
ound-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">static</=
span><span style=3D"color:#000"> intptr_t __stdcall </span><span style=3D"c=
olor:#606">Run</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#000">tef</span><span style=3D"color:#660">::</span><span style=3D"color:=
#000">sys</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">THREAD_TASK</span><span style=3D"color:#660">*</span><span style=3D"col=
or:#000"> task</span><span style=3D"color:#660">)</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">{</span><span style=3D"color:=
#000"> <br><br> </span><span style=3D"color:#606">ExclusiveTask</span=
><span style=3D"color:#660">*</span><span style=3D"color:#000"> $this </spa=
n><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><=
span style=3D"color:#008">static_cast</span><span style=3D"color:#660"><=
</span><span style=3D"color:#606">ExclusiveTask</span><span style=3D"color:=
#660">*>(</span><span style=3D"color:#000">ta<wbr>sk</span><span style=
=3D"color:#660">);</span><span style=3D"color:#000"> <br><br> </span>=
<span style=3D"color:#008">auto</span><span style=3D"color:#000"> qutex </s=
pan><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> $this<=
/span><span style=3D"color:#660">-></span><span style=3D"color:#000">qut=
ex</span><span style=3D"color:#660">;</span><span style=3D"color:#000"> <br=
><br> </span><span style=3D"color:#008">if</span><span style=3D"color=
:#660">(</span><span style=3D"color:#000"> qutex</span><span style=3D"color=
:#660">-></span><span style=3D"color:#606">Lock</span><span style=3D"col=
or:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">=3D=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#=
066">1</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</sp=
an><span style=3D"color:#000"> <br><br> $this</span><sp=
an style=3D"color:#660">-></span><span style=3D"color:#606">Callback</sp=
an><span style=3D"color:#660">();</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#800">// call back the lambda</span><span style=3D"col=
or:#000"><br><br> </span><span style=3D"color:#008">whi=
le</span><span style=3D"color:#660">(</span><span style=3D"color:#000"> qut=
ex</span><span style=3D"color:#660">-></span><span style=3D"color:#606">=
Unlock</span><span style=3D"color:#660">()</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">></span><span style=3D"color:#000"> =
</span><span style=3D"color:#066">0</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#660">)</span><span style=3D"color:#000"> </span><sp=
an style=3D"color:#660">{</span><span style=3D"color:#000"> <br><br> =
task </span><span style=3D"color:#660">=3D</span=
><span style=3D"color:#000"> qutex</span><span style=3D"color:#660">-></=
span><span style=3D"color:#606">UnsafePop</span><span style=3D"color:#660">=
();</span><span style=3D"color:#000"> <br><br> &=
nbsp;</span><span style=3D"color:#008">while</span><span style=3D"color:#66=
0">(</span><span style=3D"color:#000"> task </span><span style=3D"color:#66=
0">=3D=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">nullptr</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">)</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{=
</span><span style=3D"color:#000"> <br><br> &nbs=
p; task </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> qutex</span><span style=3D"color:#660">-></span><span style=
=3D"color:#606">UnsafePop</span><span style=3D"color:#660">();</span><span =
style=3D"color:#000"> <br><br> </span><spa=
n style=3D"color:#660">}</span><span style=3D"color:#000"> <br></span><span=
style=3D"color:rgb(136,0,0)"><span style=3D"color:#000"> &nbs=
p; </span><span style=3D"color:#800">// call back the lambda</=
span></span><span style=3D"color:#000"><br> &nbs=
p;</span><span style=3D"color:#606">ExclusiveTask</span><span style=3D"colo=
r:#660">*</span><span style=3D"color:#000"> t </span><span style=3D"color:#=
660">=3D</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">static_cast</span><span style=3D"color:#660"><</span><span style=3D"co=
lor:#606">ExclusiveTask</span><span style=3D"color:#660">*>(</span><span=
style=3D"color:#000">ta<wbr>sk</span><span style=3D"color:#660">);</span><=
span style=3D"color:#000"> <br> t</span><s=
pan style=3D"color:#660">-></span><span style=3D"color:rgb(102,0,102)"><=
span style=3D"color:#606">Callback</span></span><span style=3D"color:#660">=
();</span><span style=3D"color:#000"><br> =
</span><span style=3D"color:#008">delete</span><span style=3D"color:#000"> =
t</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><=
br> </span><span style=3D"color:#660">}</span><span sty=
le=3D"color:#000"> <br><br> </span><span style=3D"color=
:#008">delete</span><span style=3D"color:#000"> $this</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> <br><br> </span><span=
style=3D"color:#660">}</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#008">else</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> <br><br> &=
nbsp; qutex</span><span style=3D"color:#660">-></span><span style=3D"col=
or:#606">Push</span><span style=3D"color:#660">(</span><span style=3D"color=
:#000">$this</span><span style=3D"color:#660">);</span><span style=3D"color=
:#000"> <br><br> </span><span style=3D"color:#660">}</span><span styl=
e=3D"color:#000"> <br><br> </span><span style=3D"color:#008">return</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span>=
<span style=3D"color:#660">;</span><span style=3D"color:#000"> <br><br></sp=
an><span style=3D"color:#660">}</span></div></code></div><p><span><br></spa=
n></p></div><div>It is very simple, now, but it wasn't year ago. And it is =
multiple producer/single consumer queue (non-blocking, based on the atomic =
increment and compare exchange).</div><div><br></div><div>I realize that in=
the standard library thread pool creation would be explicit. Something lik=
e:</div><div><br></div><div><div style=3D"border:1px solid rgb(187,187,187)=
;word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><span s=
tyle=3D"color:#008">auto</span><span style=3D"color:#000"> h </span><span s=
tyle=3D"color:#660">=3D</span><span style=3D"color:#000"> std</span><span s=
tyle=3D"color:#660">:</span><span style=3D"color:#000">setThreadPoolSize</s=
pan><span style=3D"color:#660">(</span><span style=3D"color:#066">32</span>=
<span style=3D"color:#660">);</span></div></code></div><br></div><div>and/o=
r a thread pool handler could be passed as a parameter to forks and joins a=
lso.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex">However, I don't think the "qutex=
" concept gets us anywhere close to where we ought to be in the end.</block=
quote><div><br></div><div>What is the end? </div><div><br></div><div>I=
do not see any parallel computational model so far.</div><div>Intel TBB Fl=
ow Graph or Intel Cnc are awkward. Imagine you have to declare a call order=
of all functions of your program in advance and their call conditions.</di=
v><div>So, what is alternative? I have even more advance computational mode=
l, but it is a way out of the conventional thinking (<a href=3D"http://www.=
freepatentsonline.com/y2015/0033242.html" rel=3D"nofollow" target=3D"_blank=
" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fww=
w.freepatentsonline.com%2Fy2015%2F0033242.html\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNEQIQ4OpC7iDRbw1Xt0MyW4EI2v9Q';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fwww.freepatentsonline.com%2Fy201=
5%2F0033242.html\46sa\75D\46sntz\0751\46usg\75AFQjCNEQIQ4OpC7iDRbw1Xt0MyW4E=
I2v9Q';return true;">Method for Automatic Parallel Computing</a>).</div><di=
v><br></div><div>By the way, you used 'qutex', not 'qumex'. I am not englis=
h native speaker, so 'qumex' does not sound right?</div><div><br></div><div=
>Thanks</div><div>Andrew</div><br>On Saturday, April 4, 2015 at 3:39:15 PM =
UTC-4, Arthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr">Now that I've read more of the documentation and have a better id=
ea of the concepts involved... If I understand correctly, you start from th=
e atomic concept of<div><br></div><div> (work-queue + consumer=
-pool-of-size-N)</div><div><br></div><div>In your particular system there i=
s a singleton global (work-queue + consumer-pool-of-size-LARGE) that you ca=
ll "the thread pool", to which jobs can be submitted via gpc::fork();  =
;and your system also supports constructible-on-the-fly (work-queue + consu=
mer-pool-of-size-1)s, which you call "qutexes" and to which jobs can be sub=
mitted via qutex::join().</div><div><div><br></div><div>If anything like th=
is model were proposed for standardization, I'd hope that it would standard=
ize the underlying (work-queue + consumer-pool-of-size-N) model, so that yo=
u could have constructible-on-the-fly work-queues with consumer-pools of si=
ze 2 (for example). Perhaps the atomic concept should even *be* split=
up, so that a single consumer-pool could pull from two different work-queu=
es, etc. etc.</div><div><br></div><div>Notice that a work-queue with only a=
single producer and/or only a single consumer can be implemented with grea=
ter efficiency than a work-queue with multiple producers and/or consumers, =
so there's an efficiency win there that should be reflected in the library =
somehow. However, I don't think the "qutex" concept gets us anywhere close =
to where we ought to be in the end.</div><div><br></div><div>=E2=80=93Arthu=
r</div><br>On Saturday, April 4, 2015 at 7:46:59 AM UTC-7, <a>t...@tentity.=
com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Than=
ks. <div>Now I am thinking "qumex" which abbreviation for <b>Qu</b>eue=
of <b>M</b>utual <b>Ex</b>clusion. </div><div>Would it be better?<br>=
<br>On Friday, April 3, 2015 at 6:48:48 PM UTC-4, Arthur O'Dwyer wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Friday, April 3, 20=
15 at 5:15:13 AM UTC-7, <a>t...@tentity.com</a> wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><p></p><p><span>
</span></p><p><span>
</span></p><p><span>Quetex is Mutual Exclusion Queue. I</span>t eliminates =
blocking/waiting and thread switching in comparison to mutexes and futures.=
</p><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;ba=
ckground-color:rgb(250,250,250)"><code><div><span style=3D"color:#000"><br>=
gpc</span><span style=3D"color:#660">::</span><span style=3D"color:#0=
00">quetex</span><span style=3D"color:#080"><int></span><span style=
=3D"color:#000"> qtx</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br><br></span></div></code></div></div></blockquote><div><=
br></div><div>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. :)</div><div><br></div><div>=E2=80=93Arthur</div></div=
></blockquote></div></div></blockquote></div></div></blockquote></div></blo=
ckquote></div></div></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_752_1822152842.1428689219954--
------=_Part_751_1543097202.1428689219953--
.