I am very much in favor of wrapping a value with its protective mutex as
described in N4033. In fact, I too wrote an article about it [1].

I have some comments on the concrete proposal.

Firstly, N4033 provides three ways to access the value: directly with
the dereference operator, locked with the update_guard, and scoped with
the apply() call.

Having used a similar construct in a large codebase, we found the first
option (dereference operator) to be error-prone. Normal developers
would write incorrect statements like

   *s = *s + 1;

because dereferencing was much easier to write than using the locked
construct (update_guard.) So we ended up removing the dereference
operator altogether, which immediately removed several race conditions.

The lesson learned is that the dereference operator basically turns the
synchronizer into an atomic value (yes, I know that this is a gross
overstatement), with the challenges that follows.

I do acknowledge the usefulness of the dereference operator, so I would
like to suggest that two synchronizers are provided: one with the
dereference operator for convenience, and one without for safety.

Secondly, synchronized_value exposes a pointer interface, so shouldn't
it be called synchronized_ptr instead?

Finally, I suggest that update_guard is renamed so that its
correspondance with synchronized_value becomes more clear, e.g.
synchronized_guard or synchronized_lock.

[1] http://accu.org/var/uploads/journals/overload104.pdf

--

---
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/.

.

Le 10/06/14 12:34, Bjorn Reese a =E9crit :
> I am very much in favor of wrapping a value with its protective mutex as
> described in N4033. In fact, I too wrote an article about it [1].
>
> I have some comments on the concrete proposal.
>
> Firstly, N4033 provides three ways to access the value: directly with
> the dereference operator, locked with the update_guard, and scoped with
> the apply() call.
>
> Having used a similar construct in a large codebase, we found the first
> option (dereference operator) to be error-prone. Normal developers
> would write incorrect statements like
>
>   *s =3D *s + 1;
>
> because dereferencing was much easier to write than using the locked
> construct (update_guard.) So we ended up removing the dereference
> operator altogether, which immediately removed several race conditions.
>
> The lesson learned is that the dereference operator basically turns the
> synchronizer into an atomic value (yes, I know that this is a gross
> overstatement), with the challenges that follows.
>
> I do acknowledge the usefulness of the dereference operator, so I would
> like to suggest that two synchronizers are provided: one with the
> dereference operator for convenience, and one without for safety.
Do you mean two classes?
>
> Secondly, synchronized_value exposes a pointer interface, so shouldn't
> it be called synchronized_ptr instead?
The use of the indirection operator is due to the fact that we can not=20
overload the dot-operator. This doesn't changes anything to its value=20
nature. Other examples of classes providing value semantic and pointer=20
iterface are coming, optional<T>, expected<T,E>.
>
> Finally, I suggest that update_guard is renamed so that its
> correspondance with synchronized_value becomes more clear, e.g.
> synchronized_guard or synchronized_lock.
>
>
The update_guard class provides something more than a guard or lock. I=20
will categorize it as a locking pointer.
Boost_thread [1] uses the suffix _lock_ptr.

We can have const_strict_lock_ptr, strict_lock_ptr,=20
const_unique_lock_ptr, unique_lock_ptr.

Best,
Vicente

[1]=20
http://www.boost.org/doc/libs/1_55_0/doc/html/thread/sds.html#thread.sds.sy=
nchronized_valuesxxx.tutorial.beyond_simple_accesses


--=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/.

.

On 06/11/2014 08:55 AM, Vicente J. Botet Escriba wrote:

>> I do acknowledge the usefulness of the dereference operator, so I would
>> like to suggest that two synchronizers are provided: one with the
>> dereference operator for convenience, and one without for safety.
> Do you mean two classes?

Yes.

I wonder if the following would be possible.

Assume that synchronized_value does not have the dereference operator.
We then use synchronized_ptr (previously known as update_guard) to
access the value:

   synchronized_value<int> value;
   synchronized_ptr<int> ptr(value);
   *ptr = 42; // Changes int inside 'value'

Now, let us also allow synchronized_ptr to contain the value (indicated
by the default constructor)

   synchronized_ptr<int> ptr;
   *ptr = 42; // Changes int inside 'ptr'

Obviously, synchronized_ptr is more advanced than update_guard, because
it can operate in two modes: one owning the value, and one referencing
the value.

--

---
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/.

.