Isso mesmo.
Quando um thread tenta entrar num método sincronizado, ele faz o seguinte:
-
Verifica se algum thread está num trecho sincronizado daquele objeto de lock. Nesse caso, como o método foi declarado synchronized o objeto de lock é o próprio objeto (this);
-
Se ninguém estiver lá, ela adquire o lock e entra no bloco de código;
-
Se alguém estiver com o lock, a thread dorme, até que seja notificada ou que o lock seja liberado;
Alguns detalhes. Se a thread for notificada, mas o objeto de trava ainda não tiver sido liberado, a thread volta a dormir.
Se mais de uma thread estiver esperando pelo trecho sincronizado, não há garantia absolutamente nenhuma de qual delas irá acordar e percorrer esse trecho. Essa decisão, como tudo em threads, é deixada para o SO, que não usa nenhum critério que possamos prever (e pode mudar de SO para SO). Aliás, pode parecer tentador, mas mudar a prioridade da thread também não dá garantia nenhuma nesse caso, e geralmente, gera mais mal do que bem.
Note que, no caso da sua classe, se alguém estiver executando setRow() e alguém tentar executar sumRow(), a thread do sum irá ser colocada para dormir até que setRow() termine. Isso porque ambos os métodos usam this como lock do synchronized e nesse caso isso é o correto mesmo.
Se você quisesse fazer com que uma thread pudesse acessar cada método ao mesmo tempo (mas que somente uma thread por vez pudesse entrar no método em si), você teria que usar locks diferentes. Isso é muito comum em sockets, onde você tem threads que escrevem no socket e outras que lêem do socket. Mas duas threads ao mesmo tempo não podem tentar fazer a mesma operação.