Discussion:
[std-proposals] std::synchronized<T, M>
Michał Gawron
6 years ago
Permalink
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Klaim - Joël Lamotte
6 years ago
Permalink
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ël Lamotte
...
--
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+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OM8JiLhuAcjyEZZUtsCbfeMx6_2NCbVbKbxLbZNQDSNBQ%40mail.gmail.com.
Michał Gawron
6 years ago
Permalink
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.

On Tuesday, September 18, 2018 at 12:44:40 AM UTC+2, Klaim - Joël Lamotte
...
--
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+***@isocpp.org.
To post to this group, send email to std-***@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.org.
Klaim - Joël Lamotte
6 years ago
Permalink
Post by Michał Gawron
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.
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ël
--
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+***@isocpp.org.
To post to this group, send email to std-***@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOU91OPB1%3DUG6QK6P1UtbqwdT1998tQhR5B2YFc_at%3DZ4sR9bw%40mail.gmail.com.
Michał Gawron
6 years ago
Permalink
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+***@isocpp.org.
To post to this group, send email to std-***@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.
Continue reading on narkive:
Loading...