On Wednesday, 5 October 2016 at 12:48:07 UTC, Jonathan M Davis
wrote:
On Wednesday, October 05, 2016 11:25:57 Begah via
Digitalmars-d-learn wrote:
[...]
Unless you're writing lock-free algorithms (which really should
only be done by experts, and even then, they should probably
reconsider it, since they're so insanely hard to get right),
_every_ variable/object that's going to be accessible from
multiple threads needs to be protected by a mutex so that it's
guaranteed that only one thread accesses the object at a time.
That would be just as true in C/C++ as it is in D. It's just
that D requires that they be marked as shared. That being said,
how many objects should be protected by a given mutex depends
entirely on what you're doing. In some cases, it makes sense to
protect a lot of objects with the same mutex (e.g. all of the
member variables of a class could be protected with a single
mutex, which is what would happen with synchronized
functions/classes), and in other cases, it makes sense to have
as many as a mutex per variable. Having fewer mutexes is easier
to handle, but it can also mean that code gets blocked waiting
more. And of course, in some cases, the state in question is
really spread across multiple variables, and they all need to
be protected together. I really can't judge how many mutexes
would be needed without knowing what you're doing.
[...]
Thanks,
Although the triple buffer seems a good idea, there is one
problem.
I will need three time as much ram than what i currently need.
Not to mention, every time i switch buffer i will need to copy
all changes made to the updated buffer to the next buffer to be
updated (Which i think, doing it a few hundred times a second
might become a bottleneck ).
