On 30-05-2012 00:35, Jonathan M Davis wrote:
On Wednesday, May 30, 2012 00:01:49 Alex Rønne Petersen wrote:
Besides, it seems to me that D can't quite make up its mind. We have TLS
by default, and we encourage message-passing (through a library
mechanism), and then we have the synchronized statement and attribute.
It just seems so incredibly inconsistent. synchronized encourages doing
the wrong thing (locks and synchronization).

It allows multiple approaches at multiple levels. TLS and message passing is
the preferred way, and shared combined with synchronized or mutexes to protect
it is available when you need it. synchronized classes are more
straightforward approach to locking when you need to protect an entire object
(and less error-prone in some respects, because you then have the guarantee
that it happens for all functions and don't run the risk of not locking in
some functions; it also works with inheritance that way, unlike mutexes).
sychronized blocks on the other hand are a quick and easy way to protect
specific sections of code without having to bother creating mutexes for it. And
mutexes are available when you need full control. Which approach you go with
depends on what you're doing and what your needs are.

I agree on your point about synchronized blocks, but not about synchronized classes. Synchronized classes lock on the this reference, which is exactly what should be avoided.


Now, I could definitely see an argument that using shared is more low level and
that it would be just simpler to only have mutexes and no synchronized, but we
ended up with a more tiered approach, and that's not all bad. Each approach
has its advantages and disadvantages, and D gives you all of them, so you can
pick and choose what works best for you.

- Jonathan M Davis

To be clear, I have nothing against synchronized blocks per se. I think it's fine to have them in the language. But I think that making *every* object a monitor is a horrible mistake (for reasons I outlined in another post in this thread). Synchronized blocks are good because they operate on an implicit, hidden, global mutex. You can't screw up with that.

Synchronized blocks that operate on a specific object should be limited somehow so not every object has to have a monitor field.

--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org

Reply via email to