Date: Thu, 1 Jun 2023 00:42:45 -0400
On 6/1/23 00:20, Thiago Macieira wrote:
> On Wednesday, 31 May 2023 20:46:37 PDT Phil Bouchard wrote:
>>> How? It's no different than using a mutex, because it is using a mutex. So
>>> if it is not different, how is it better?
>>
>> Because it is abstracted thus done implicitly.
>
> And yet there's still a lock and the user must know that it is there. The
> normal code one would write
> if (!container.empty())
> container.push)back(1);
>
> is not safe.
Why? The mutex is recursive so it just gives priority to the current
thread for the scope of the condition.
But you might have problems for child threads:
if (!container.empty())
std::thread
(
[&]()
{
container.push_back(1);
}
};
So we'll need "child-recursive" mutices.
> Is the code above meant to fail t compile? If so, how do you
> propose that happen? If not, how do you propose we change our teaching methods
> of thread-safe code so that developers will know this, instead of knowing the
> regular mutex API?
>
> And this of course becomes more complex when you have two or more containers.
> Here's the first part of an algorithm: given containers C1 and C2, if the first
> element in C1 isn't in C2, then remove it from there (pop_front) and append
> (push_bacl) to C2.
>
> If you realise what the second part will be, feel free to comment on it and
> explain how your API will ensure the user writes the proper code for that.
// imagine both containers are locked here for the scope of the condition:
if (find(C2.begin(), C2.end(), * C1.begin()) != C2.end())
{
T value = C1.front();
C1.pop_front();
C2.push_back(value);
}
Again, where's the problem if both containers feature a recursive mutex?
Regarding teaching, this is higher-level programming so a new namespace
should encompass these new classes.
> On Wednesday, 31 May 2023 20:46:37 PDT Phil Bouchard wrote:
>>> How? It's no different than using a mutex, because it is using a mutex. So
>>> if it is not different, how is it better?
>>
>> Because it is abstracted thus done implicitly.
>
> And yet there's still a lock and the user must know that it is there. The
> normal code one would write
> if (!container.empty())
> container.push)back(1);
>
> is not safe.
Why? The mutex is recursive so it just gives priority to the current
thread for the scope of the condition.
But you might have problems for child threads:
if (!container.empty())
std::thread
(
[&]()
{
container.push_back(1);
}
};
So we'll need "child-recursive" mutices.
> Is the code above meant to fail t compile? If so, how do you
> propose that happen? If not, how do you propose we change our teaching methods
> of thread-safe code so that developers will know this, instead of knowing the
> regular mutex API?
>
> And this of course becomes more complex when you have two or more containers.
> Here's the first part of an algorithm: given containers C1 and C2, if the first
> element in C1 isn't in C2, then remove it from there (pop_front) and append
> (push_bacl) to C2.
>
> If you realise what the second part will be, feel free to comment on it and
> explain how your API will ensure the user writes the proper code for that.
// imagine both containers are locked here for the scope of the condition:
if (find(C2.begin(), C2.end(), * C1.begin()) != C2.end())
{
T value = C1.front();
C1.pop_front();
C2.push_back(value);
}
Again, where's the problem if both containers feature a recursive mutex?
Regarding teaching, this is higher-level programming so a new namespace
should encompass these new classes.
-- Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> Founder & CEO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 8 rue de la Baie| Gatineau (Qc), J8T 3H3 Canada Banner <https://goglobalawards.org/> Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.
Received on 2023-06-01 04:42:47