------=_Part_1887_190769768.1537221965751
Content-Type: multipart/alternative;
 boundary="----=_Part_1888_301735935.1537221965752"

------=_Part_1888_301735935.1537221965752
Content-Type: text/plain; charset="UTF-8"

Hello everyone.

I have a standard library feature idea. I don't know if anything similar
was proposed before, please point me to the post or article if it was.

The idea is for synchronized<T, M> class that wraps any data that needs to
be accessed concurrently. T is the resource type, M is the mutex type.

It's about protecting a resource, not a section of code.

It can return a unique_accessor<T, M> via the lock() method (an analogy to
std::weak_ptr<>::lock()). The accessor  accesses the protected resouce (via
operator* and operator->). There's no other way to access the resource,
synchronized<> would not have any methods returning reference or pointer to
the resource.

A unique_accessor<> can only be created by synchronized<>, but it would
still be moveable. It can be very easily implemented with unique_lock<M>.

If a thread wants to access the resource, it calls lock() on synchronized<>
object. The method blocks if there's another unique_accessor<> existing in
the program. Otherwise returns new accessor to use. Resource is unlocked
when accessor is destroyed.

Why I'm even talking about this? Because the typical way of making sure
that resource is not accessed concurrently (or in parallel) is to use
separate mutex, like so:

SomeType    resource;
std::mutex  lock_for_the_resource;

The problems with the above is that resource and the lock are separate.
That means:

1. Possibility of forgetting to lock the mutex when writing code that uses
the resource.
2. Not knowing that the mutex needs to be locked at all.
3. When API changes, forgetting to refactor all usage of the resource and
   lock the mutex in all places.

synchronized<> should solve all three points.

I've written such class for myself and used it on several occasions in my
project.
Example usage from my code:

// Member variable:
xf::Synchronized<Data> mutable _data; // Yes, in my code it's really called
"Data" ;-)

....

// A method:
{
  auto data = _data.lock();


  if (!data->cached_aids || !data->cached_canvas_metric || *data->cached_canvas_metric
!= paint_request.metric())
    update_cache (paint_request, *data);


  return data->cached_aids;
}



*_parameters.lock() = new_params; // Simple enough, without creating new
scope and inventing name for a std::unique_lock<>


My implementation can be seen here:
<https://github.com/mcvsama/xefis/blob/v02-c/src/xefis/utility/synchronized.h>

Things that may need futher thinking:

* std::lock() algorithm for multiple synchronize<> objects (for
dead-lock-free locking).

* Maybe splitting unique_accessor<> to read-only and writeable versions,
allowing more than one read-only objects to exist at the same time,
  but only one writeable accessor (and of course no other, including
read-only, accessors would be allowed to exist when writing accessor
exists).

What do you think?

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a1e06720-1e13-4e42-b056-d04b4fb7630b%40isocpp.org.

------=_Part_1888_301735935.1537221965752
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><span style=3D"font-size: 13px;">Hello everyone.</spa=
n></div><div><span style=3D"font-size: 13px;"><br></span></div><div><span s=
tyle=3D"font-size: 13px;">I have a standard library feature idea. I don&#39=
;t know if anything similar was proposed before, please point me to the=C2=
=A0</span>post or article if it was.</div><div><span style=3D"font-size: 13=
px;"><br></span></div><div><span style=3D"font-size: 13px;">The idea is for=
 <font face=3D"courier new, monospace">synchronized&lt;T, M&gt;</font> clas=
s that wraps any data that needs=C2=A0</span>to be accessed concurrently. T=
 is the resource type, M is the mutex type.</div><div><span style=3D"font-s=
ize: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">It&#39;s=
 about protecting a resource, not a section of code.</span></div><div><span=
 style=3D"font-size: 13px;"><br></span></div><div><span style=3D"font-size:=
 13px;">It can return a<font face=3D"courier new, monospace"> unique_access=
or&lt;T, M&gt;</font> via the <font face=3D"courier new, monospace">lock()<=
/font>=C2=A0</span>method (an analogy to <font face=3D"courier new, monospa=
ce">std::weak_ptr&lt;&gt;::lock()</font>). The accessor=C2=A0 accesses the =
protected resouce (via <font face=3D"courier new, monospace">operator*</fon=
t> and <font face=3D"courier new, monospace">operator-&gt;</font>). There&#=
39;s no other way to access the=C2=A0resource, <font face=3D"courier new, m=
onospace">synchronized&lt;&gt;</font> would not have any methods returning =
reference or pointer to the resource.</div><div><span style=3D"font-size: 1=
3px;"><br></span></div><div><span style=3D"font-size: 13px;">A <font face=
=3D"courier new, monospace">unique_accessor&lt;&gt;</font> can only be crea=
ted by <font face=3D"courier new, monospace">synchronized&lt;&gt;</font>, b=
ut it=C2=A0</span>would still be moveable. It can be very easily implemente=
d with <font face=3D"courier new, monospace">unique_lock&lt;M&gt;</font>.</=
div><div><span style=3D"font-size: 13px;"><br></span></div><div><span style=
=3D"font-size: 13px;">If a thread wants to access the resource, it calls <f=
ont face=3D"courier new, monospace">lock()</font> on <font face=3D"courier =
new, monospace">synchronized&lt;&gt;</font> object.=C2=A0</span>The method =
blocks if there&#39;s another <font face=3D"courier new, monospace">unique_=
accessor&lt;&gt;</font> existing in the program. Otherwise returns new acce=
ssor to use. Resource is unlocked when accessor is destroyed.</div><div><sp=
an style=3D"font-size: 13px;"><br></span></div><div><span style=3D"font-siz=
e: 13px;">Why I&#39;m even talking about this? Because the typical way of m=
aking sure that resource=C2=A0</span>is not accessed concurrently (or in pa=
rallel) is to use separate mutex, like so:</div><div><span style=3D"font-si=
ze: 13px;"><br></span></div><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">SomeType</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> =C2=A0 =C2=A0resource</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>std</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">mutex =C2=A0lock_for_the_resource</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span></div></code></div><div><span style=3D=
"font-size: 13px;"></span></div><div><span style=3D"font-size: 13px;"><br><=
/span></div><div><span style=3D"font-size: 13px;">The problems with the abo=
ve is that resource and the lock are separate.</span></div><div><span style=
=3D"font-size: 13px;">That means:</span></div><div><span style=3D"font-size=
: 13px;"><br></span></div><div><span style=3D"font-size: 13px;"><span style=
=3D"white-space:pre"> </span>1. Possibility of forgetting to lock the mutex=
 when writing code that uses the resource.</span></div><div><span style=3D"=
font-size: 13px;"><span style=3D"white-space:pre"> </span>2. Not knowing th=
at the mutex needs to be locked at all.</span></div><div><span style=3D"fon=
t-size: 13px;"><span style=3D"white-space:pre"> </span>3. When API changes,=
 forgetting to refactor all usage of the resource and</span></div><div><spa=
n style=3D"font-size: 13px;"><span style=3D"white-space:pre"> </span>=C2=A0=
 =C2=A0lock the mutex in all places.</span></div><div><span style=3D"font-s=
ize: 13px;"><br></span></div><div><span style=3D"font-size: 13px;"><font fa=
ce=3D"courier new, monospace">synchronized&lt;&gt;</font>=C2=A0should solve=
 all three points.</span></div><div><span style=3D"font-size: 13px;"><br></=
span></div><div><span style=3D"font-size: 13px;">I&#39;ve written such clas=
s for myself and used it on several occasions in my project.</span></div><d=
iv><span style=3D"font-size: 13px;">Example usage from my code:</span></div=
><div><span style=3D"font-size: 13px;"><br></span></div><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #800;" class=3D"styled-by-prettify">// Member variable:</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>xf</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Synchronized</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color:=
 #606;" class=3D"styled-by-prettify">Data</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">mutable</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> _data</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// Yes, i=
n my code it&#39;s really called &quot;Data&quot; ;-)</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"co=
lor: #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: #800=
;" class=3D"styled-by-prettify">// A method:</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><font color=3D"#000000"><span style=3D"color:=
 #000;" class=3D"styled-by-prettify">=C2=A0 </span></font><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> data </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> _data</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">lock</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br><br></span><font color=3D"#000000"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">=C2=A0 </span></font><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">if</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-prettif=
y">data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&g=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cached_a=
ids </span><span style=3D"color: #660;" class=3D"styled-by-prettify">||</sp=
an><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">data</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">cached_canvas_metric </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;" cla=
ss=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">data</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">cached_canvas_metric </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">!=3D</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> paint_request</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">metric</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">())</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 update_cache </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">paint_request</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">data</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><font col=
or=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify">=
=C2=A0 </span></font><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 data</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cached_aid=
s</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 s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div=
><div><br><br></div><div><span style=3D"font-size: 13px;"><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">_parameters</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">lock</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 new_params</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: #800;" class=3D"styled-by-prettify">// Simple enough,=
 without creating new scope and inventing name for a std::unique_lock&lt;&g=
t;</span></div></code></div><br></span></div><div><br></div><div><span styl=
e=3D"font-size: 13px;">My implementation can be seen here:</span></div><div=
><span style=3D"font-size: 13px;">&lt;https://github.com/mcvsama/xefis/blob=
/v02-c/src/xefis/utility/synchronized.h&gt;</span></div><div><span style=3D=
"font-size: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">T=
hings that may need futher thinking:</span></div><div><span style=3D"font-s=
ize: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">* <font =
face=3D"courier new, monospace">std::lock()</font> algorithm for multiple <=
font face=3D"courier new, monospace">synchronize&lt;&gt;</font> objects (fo=
r dead-lock-free locking).</span></div><div><span style=3D"font-size: 13px;=
"><br></span></div><div><span style=3D"font-size: 13px;">* Maybe splitting =
<font face=3D"courier new, monospace">unique_accessor&lt;&gt;</font> to rea=
d-only and writeable versions, allowing more than one read-only objects to =
exist at the same time,</span></div><div><span style=3D"font-size: 13px;">=
=C2=A0 but only one writeable accessor (and of course no other, including r=
ead-only, accessors would be allowed to exist when writing accessor exists)=
..</span></div><div><span style=3D"font-size: 13px;"><br></span></div><div><=
span style=3D"font-size: 13px;">What do you think?</span></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a1e06720-1e13-4e42-b056-d04b4fb7630b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1e06720-1e13-4e42-b056-d04b4fb7630b=
%40isocpp.org</a>.<br />

------=_Part_1888_301735935.1537221965752--

------=_Part_1887_190769768.1537221965751--

.

Is this basically:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4033.html ?
(also see boost::synchronized_value in Boost.Thread, and the last
followup to that proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0290r2.html )

A. Jo=C3=ABl Lamotte

On Tue, 18 Sep 2018 at 00:06, Micha=C5=82 Gawron <mcvsama@gmail.com> wrote:
>
> Hello everyone.
>
> I have a standard library feature idea. I don't know if anything similar =
was proposed before, please point me to the post or article if it was.
>
> The idea is for synchronized<T, M> class that wraps any data that needs t=
o be accessed concurrently. T is the resource type, M is the mutex type.
>
> It's about protecting a resource, not a section of code.
>
> It can return a unique_accessor<T, M> via the lock() method (an analogy t=
o std::weak_ptr<>::lock()). The accessor  accesses the protected resouce (v=
ia operator* and operator->). There's no other way to access the resource, =
synchronized<> would not have any methods returning reference or pointer to=
 the resource.
>
> A unique_accessor<> can only be created by synchronized<>, but it would s=
till be moveable. It can be very easily implemented with unique_lock<M>.
>
> If a thread wants to access the resource, it calls lock() on synchronized=
<> object. The method blocks if there's another unique_accessor<> existing =
in the program. Otherwise returns new accessor to use. Resource is unlocked=
 when accessor is destroyed.
>
> Why I'm even talking about this? Because the typical way of making sure t=
hat resource is not accessed concurrently (or in parallel) is to use separa=
te mutex, like so:
>
> SomeType    resource;
> std::mutex  lock_for_the_resource;
>
> The problems with the above is that resource and the lock are separate.
> That means:
>
> 1. Possibility of forgetting to lock the mutex when writing code that use=
s the resource.
> 2. Not knowing that the mutex needs to be locked at all.
> 3. When API changes, forgetting to refactor all usage of the resource and
>    lock the mutex in all places.
>
> synchronized<> should solve all three points.
>
> I've written such class for myself and used it on several occasions in my=
 project.
> Example usage from my code:
>
> // Member variable:
> xf::Synchronized<Data> mutable _data; // Yes, in my code it's really call=
ed "Data" ;-)
>
> ...
>
> // A method:
> {
>   auto data =3D _data.lock();
>
>
>   if (!data->cached_aids || !data->cached_canvas_metric || *data->cached_=
canvas_metric !=3D paint_request.metric())
>     update_cache (paint_request, *data);
>
>
>   return data->cached_aids;
> }
>
>
>
> *_parameters.lock() =3D new_params; // Simple enough, without creating ne=
w scope and inventing name for a std::unique_lock<>
>
>
> My implementation can be seen here:
> <https://github.com/mcvsama/xefis/blob/v02-c/src/xefis/utility/synchroniz=
ed.h>
>
> Things that may need futher thinking:
>
> * std::lock() algorithm for multiple synchronize<> objects (for dead-lock=
-free locking).
>
> * Maybe splitting unique_accessor<> to read-only and writeable versions, =
allowing more than one read-only objects to exist at the same time,
>   but only one writeable accessor (and of course no other, including read=
-only, accessors would be allowed to exist when writing accessor exists).
>
> What do you think?
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/a/isoc=
pp.org/d/msgid/std-proposals/a1e06720-1e13-4e42-b056-d04b4fb7630b%40isocpp.=
org.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OM8JiLhuAcjyEZZUtsCbfeMx6_2NCbVbKbxLbZNQDS=
NBQ%40mail.gmail.com.

.

------=_Part_1853_1162680934.1537249574397
Content-Type: multipart/alternative;
 boundary="----=_Part_1854_334888053.1537249574398"

------=_Part_1854_334888053.1537249574398
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Yes, it is!

It doesn't look like this is going to be implemented in C++20, does it?=20
Boost stuff is still marked as experimental. But it's good to see it in=20
Boost at least.

On Tuesday, September 18, 2018 at 12:44:40 AM UTC+2, Klaim - Jo=C3=ABl Lamo=
tte=20
wrote:
>
> Is this basically:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4033.html ?=20
> (also see boost::synchronized_value in Boost.Thread, and the last=20
> followup to that proposal:=20
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0290r2.html )=20
>
> A. Jo=C3=ABl Lamotte=20
>
> On Tue, 18 Sep 2018 at 00:06, Micha=C5=82 Gawron <mcv...@gmail.com=20
> <javascript:>> wrote:=20
> >=20
> > Hello everyone.=20
> >=20
> > I have a standard library feature idea. I don't know if anything simila=
r=20
> was proposed before, please point me to the post or article if it was.=20
> >=20
> > The idea is for synchronized<T, M> class that wraps any data that needs=
=20
> to be accessed concurrently. T is the resource type, M is the mutex type.=
=20
> >=20
> > It's about protecting a resource, not a section of code.=20
> >=20
> > It can return a unique_accessor<T, M> via the lock() method (an analogy=
=20
> to std::weak_ptr<>::lock()). The accessor  accesses the protected resouce=
=20
> (via operator* and operator->). There's no other way to access the=20
> resource, synchronized<> would not have any methods returning reference o=
r=20
> pointer to the resource.=20
> >=20
> > A unique_accessor<> can only be created by synchronized<>, but it would=
=20
> still be moveable. It can be very easily implemented with unique_lock<M>.=
=20
> >=20
> > If a thread wants to access the resource, it calls lock() on=20
> synchronized<> object. The method blocks if there's another=20
> unique_accessor<> existing in the program. Otherwise returns new accessor=
=20
> to use. Resource is unlocked when accessor is destroyed.=20
> >=20
> > Why I'm even talking about this? Because the typical way of making sure=
=20
> that resource is not accessed concurrently (or in parallel) is to use=20
> separate mutex, like so:=20
> >=20
> > SomeType    resource;=20
> > std::mutex  lock_for_the_resource;=20
> >=20
> > The problems with the above is that resource and the lock are separate.=
=20
> > That means:=20
> >=20
> > 1. Possibility of forgetting to lock the mutex when writing code that=
=20
> uses the resource.=20
> > 2. Not knowing that the mutex needs to be locked at all.=20
> > 3. When API changes, forgetting to refactor all usage of the resource=
=20
> and=20
> >    lock the mutex in all places.=20
> >=20
> > synchronized<> should solve all three points.=20
> >=20
> > I've written such class for myself and used it on several occasions in=
=20
> my project.=20
> > Example usage from my code:=20
> >=20
> > // Member variable:=20
> > xf::Synchronized<Data> mutable _data; // Yes, in my code it's really=20
> called "Data" ;-)=20
> >=20
> > ...=20
> >=20
> > // A method:=20
> > {=20
> >   auto data =3D _data.lock();=20
> >=20
> >=20
> >   if (!data->cached_aids || !data->cached_canvas_metric ||=20
> *data->cached_canvas_metric !=3D paint_request.metric())=20
> >     update_cache (paint_request, *data);=20
> >=20
> >=20
> >   return data->cached_aids;=20
> > }=20
> >=20
> >=20
> >=20
> > *_parameters.lock() =3D new_params; // Simple enough, without creating =
new=20
> scope and inventing name for a std::unique_lock<>=20
> >=20
> >=20
> > My implementation can be seen here:=20
> > <
> https://github.com/mcvsama/xefis/blob/v02-c/src/xefis/utility/synchronize=
d.h>=20
>
> >=20
> > Things that may need futher thinking:=20
> >=20
> > * std::lock() algorithm for multiple synchronize<> objects (for=20
> dead-lock-free locking).=20
> >=20
> > * Maybe splitting unique_accessor<> to read-only and writeable versions=
,=20
> allowing more than one read-only objects to exist at the same time,=20
> >   but only one writeable accessor (and of course no other, including=20
> read-only, accessors would be allowed to exist when writing accessor=20
> exists).=20
> >=20
> > What do you think?=20
> >=20
> > --=20
> > You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > To view this discussion on the web visit=20
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a1e06720-1e1=
3-4e42-b056-d04b4fb7630b%40isocpp.org.=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/445075b5-aa1d-4e71-9682-864d78156184%40isocpp.or=
g.

------=_Part_1854_334888053.1537249574398
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, it is!<div><br></div><div>It doesn&#39;t look like th=
is is going to be implemented in C++20, does it? Boost stuff is still marke=
d as experimental. But it&#39;s good to see it in Boost at least.<br><br>On=
 Tuesday, September 18, 2018 at 12:44:40 AM UTC+2, Klaim - Jo=C3=ABl Lamott=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Is this basically:
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n403=
3.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4033.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x=
3dAFQjCNHtQQLmwZgK4Z51FNwOHpUHWYFlHA&#39;;return true;" onclick=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4033.html\x26sa\x3dD\x26sntz\x3d1=
\x26usg\x3dAFQjCNHtQQLmwZgK4Z51FNwOHpUHWYFlHA&#39;;return true;">http://www=
..open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr>n4033.html</a> ?
<br>(also see boost::synchronized_value in Boost.Thread, and the last
<br>followup to that proposal:
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p029=
0r2.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc2=
2%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0290r2.html\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNE_c_5my65XQRi6EAku_QCTVq3Fgg&#39;;return true;" onclick=3D"this=
..href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.org%2=
Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2017%2Fp0290r2.html\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNE_c_5my65XQRi6EAku_QCTVq3Fgg&#39;;return true;">http=
://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2017/<wbr>p0290r2.html<=
/a> )
<br>
<br>A. Jo=C3=ABl Lamotte
<br>
<br>On Tue, 18 Sep 2018 at 00:06, Micha=C5=82 Gawron &lt;<a href=3D"javascr=
ipt:" target=3D"_blank" gdf-obfuscated-mailto=3D"1MPmAVyyCAAJ" rel=3D"nofol=
low" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">mcv...@gmail.com</a>&gt=
; wrote:
<br>&gt;
<br>&gt; Hello everyone.
<br>&gt;
<br>&gt; I have a standard library feature idea. I don&#39;t know if anythi=
ng similar was proposed before, please point me to the post or article if i=
t was.
<br>&gt;
<br>&gt; The idea is for synchronized&lt;T, M&gt; class that wraps any data=
 that needs to be accessed concurrently. T is the resource type, M is the m=
utex type.
<br>&gt;
<br>&gt; It&#39;s about protecting a resource, not a section of code.
<br>&gt;
<br>&gt; It can return a unique_accessor&lt;T, M&gt; via the lock() method =
(an analogy to std::weak_ptr&lt;&gt;::lock()). The accessor =C2=A0accesses =
the protected resouce (via operator* and operator-&gt;). There&#39;s no oth=
er way to access the resource, synchronized&lt;&gt; would not have any meth=
ods returning reference or pointer to the resource.
<br>&gt;
<br>&gt; A unique_accessor&lt;&gt; can only be created by synchronized&lt;&=
gt;, but it would still be moveable. It can be very easily implemented with=
 unique_lock&lt;M&gt;.
<br>&gt;
<br>&gt; If a thread wants to access the resource, it calls lock() on synch=
ronized&lt;&gt; object. The method blocks if there&#39;s another unique_acc=
essor&lt;&gt; existing in the program. Otherwise returns new accessor to us=
e. Resource is unlocked when accessor is destroyed.
<br>&gt;
<br>&gt; Why I&#39;m even talking about this? Because the typical way of ma=
king sure that resource is not accessed concurrently (or in parallel) is to=
 use separate mutex, like so:
<br>&gt;
<br>&gt; SomeType =C2=A0 =C2=A0resource;
<br>&gt; std::mutex =C2=A0lock_for_the_resource;
<br>&gt;
<br>&gt; The problems with the above is that resource and the lock are sepa=
rate.
<br>&gt; That means:
<br>&gt;
<br>&gt; 1. Possibility of forgetting to lock the mutex when writing code t=
hat uses the resource.
<br>&gt; 2. Not knowing that the mutex needs to be locked at all.
<br>&gt; 3. When API changes, forgetting to refactor all usage of the resou=
rce and
<br>&gt; =C2=A0 =C2=A0lock the mutex in all places.
<br>&gt;
<br>&gt; synchronized&lt;&gt; should solve all three points.
<br>&gt;
<br>&gt; I&#39;ve written such class for myself and used it on several occa=
sions in my project.
<br>&gt; Example usage from my code:
<br>&gt;
<br>&gt; // Member variable:
<br>&gt; xf::Synchronized&lt;Data&gt; mutable _data; // Yes, in my code it&=
#39;s really called &quot;Data&quot; ;-)
<br>&gt;
<br>&gt; ...
<br>&gt;
<br>&gt; // A method:
<br>&gt; {
<br>&gt; =C2=A0 auto data =3D _data.lock();
<br>&gt;
<br>&gt;
<br>&gt; =C2=A0 if (!data-&gt;cached_aids || !data-&gt;cached_canvas_metric=
 || *data-&gt;cached_canvas_metric !=3D paint_request.metric())
<br>&gt; =C2=A0 =C2=A0 update_cache (paint_request, *data);
<br>&gt;
<br>&gt;
<br>&gt; =C2=A0 return data-&gt;cached_aids;
<br>&gt; }
<br>&gt;
<br>&gt;
<br>&gt;
<br>&gt; *_parameters.lock() =3D new_params; // Simple enough, without crea=
ting new scope and inventing name for a std::unique_lock&lt;&gt;
<br>&gt;
<br>&gt;
<br>&gt; My implementation can be seen here:
<br>&gt; &lt;<a href=3D"https://github.com/mcvsama/xefis/blob/v02-c/src/xef=
is/utility/synchronized.h" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.c=
om%2Fmcvsama%2Fxefis%2Fblob%2Fv02-c%2Fsrc%2Fxefis%2Futility%2Fsynchronized.=
h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGny4UlbFC1J8FSxp3ackgfPISyA&#39;=
;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3d=
https%3A%2F%2Fgithub.com%2Fmcvsama%2Fxefis%2Fblob%2Fv02-c%2Fsrc%2Fxefis%2Fu=
tility%2Fsynchronized.h\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEGny4UlbFC1=
J8FSxp3ackgfPISyA&#39;;return true;">https://github.com/mcvsama/<wbr>xefis/=
blob/v02-c/src/xefis/<wbr>utility/synchronized.h</a>&gt;
<br>&gt;
<br>&gt; Things that may need futher thinking:
<br>&gt;
<br>&gt; * std::lock() algorithm for multiple synchronize&lt;&gt; objects (=
for dead-lock-free locking).
<br>&gt;
<br>&gt; * Maybe splitting unique_accessor&lt;&gt; to read-only and writeab=
le versions, allowing more than one read-only objects to exist at the same =
time,
<br>&gt; =C2=A0 but only one writeable accessor (and of course no other, in=
cluding read-only, accessors would be allowed to exist when writing accesso=
r exists).
<br>&gt;
<br>&gt; What do you think?
<br>&gt;
<br>&gt; --
<br>&gt; You received this message because you are subscribed to the Google=
 Groups &quot;ISO C++ Standard - Future Proposals&quot; group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"1MPmAVyyCAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;re=
turn true;">std-proposal...@<wbr>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"1MPmAVyyCAAJ" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.
<br>&gt; To view this discussion on the web visit <a href=3D"https://groups=
..google.com/a/isocpp.org/d/msgid/std-proposals/a1e06720-1e13-4e42-b056-d04b=
4fb7630b%40isocpp.org" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-proposals=
/a1e06720-1e13-4e42-b056-d04b4fb7630b%40isocpp.org&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/std-p=
roposals/a1e06720-1e13-4e42-b056-d04b4fb7630b%40isocpp.org&#39;;return true=
;">https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a=
1e06720-1e13-4e42-<wbr>b056-d04b4fb7630b%40isocpp.org</a><wbr>.
<br></blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/445075b5-aa1d-4e71-9682-864d78156184%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/445075b5-aa1d-4e71-9682-864d78156184=
%40isocpp.org</a>.<br />

------=_Part_1854_334888053.1537249574398--

------=_Part_1853_1162680934.1537249574397--

.

------=_Part_1991_1546952488.1537249649458
Content-Type: multipart/alternative;
 boundary="----=_Part_1992_324080125.1537249649458"

------=_Part_1992_324080125.1537249649458
Content-Type: text/plain; charset="UTF-8"

Yes, it is!

It doesn't look like this is going to be implemented in C++20, does it?
Boost stuff is still marked as experimental. But it's good to see it in
Boost at least.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4a86bcfb-49f2-4dcf-b1de-1f41d7e21a94%40isocpp.org.

------=_Part_1992_324080125.1537249649458
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, it is!<div><br></div><div>It doesn&#39;t look like th=
is is going to be implemented in C++20, does it? Boost stuff is still marke=
d as experimental. But it&#39;s good to see it in Boost at least.</div><div=
><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4a86bcfb-49f2-4dcf-b1de-1f41d7e21a94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a86bcfb-49f2-4dcf-b1de-1f41d7e21a94=
%40isocpp.org</a>.<br />

------=_Part_1992_324080125.1537249649458--

------=_Part_1991_1546952488.1537249649458--

.

On Tue, 18 Sep 2018 at 07:46, Micha=C5=82 Gawron <mcvsama@gmail.com> wrote:
>
> Yes, it is!
>
> It doesn't look like this is going to be implemented in C++20, does it? B=
oost stuff is still marked as experimental. But it's good to see it in Boos=
t at least.
>

I think you should ask directly to the author of the last version of
the proposal, see how it goes.
Because it is a library feature, it still have time to get in.
November will fix what the language will look like, big-feature-wise,
but it will not yet fix the library as it is more flexible to modify.

Jo=C3=ABl

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OPB1%3DUG6QK6P1UtbqwdT1998tQhR5B2YFc_at%3D=
Z4sR9bw%40mail.gmail.com.

.