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