Desempenho de threads

Eu recomendaria que você fizesse um benchmark. A princípio, você deve reservar essa classe Condition para os casos em que o uso simples dos monitores já presentes na própria linguagem não seja suficiente. É que a JVM tem um recurso de “lock coarsening” que não sei se é válido para qualquer lock, ou apenas para os locks gerados pelas primitivas da linguagem. http://java.sun.com/performance/reference/whitepapers/6_performance.html#2.1.2

Surgiu uma dúvida aqui sobre o uso de synchronized.

Quando eu usava Condition, antes de entrar em uma região crítica, eu usava o método (new Reentrant).lock() de Lock.
Assim, quando dois métodos, p. ex. , Ler() e Escrever() não podiam entrar simultaneamente em suas regiões críticas. Quem entrasse primeiro, receberia o lock. Quem chegasse por último, ficaria em espera pela liberação do lock. Tudo isso era possível porque o lock usado em ambos os métodos eram iguais.

Usando synchronized, não preciso de lock, mas também não entendo uma coisa. Tudo bem que duas thread não conseguem entrar no mesmo método ao mesmo tempo, mas uma thread pode entrar no método Ler() e outra thread no Escrever(), não é?!

Antes eu sabia que ou a thread escrevia ou a thread lia. Agora eu não tenho mais controle disso.

Alguém me ajuda?

Se você estiver falando em ler e escrever no mesmo objeto, o bloco synchronized vai evitar que as duas threads façam isso ao mesmo tempo