Estive estudando algumas alternativas para melhor solucionar meu problema de criar três grupos de threads onde todas precisam funcionar ora como produtoras ora como consumidoras. Estes três grupos precisarão trocar informações, i.e., algumas vezes o grupo 1 pode ser produtor para o grupo 2 e o grupo 2 produtor para o grupo 3.
Diante das alternativas que li: ThreadGroup, Work Queue, SynchronizedBuffer e ArrayBlockingQueue, pensei em criar 3 buffers de dados, para proporcionar a sincronização em cada grupo e permitir a “troca” de dados entre eles, mas não estou certa se seria a melhor saída…
Outra dúvida é quando à sincronização proporcionada pelo buffer pois, quando não existirem dados para serem consumidos, eu tenho uma ação default a ser executada e na maioria das vezes não será necessário esperar para que um dado seja produzido.
Resumindo: acho que neste caso não preciso utilizar threads, certo?
Você pode usar threads com os BlockingQueues sim. É uma boa alternativa. Quanto ao problema do que ocorre quando a fila está vazia, você pode fazer pooling das filas em vez de chamadas que esperam.
Sua certeza me fez batalhar nessa direção e valeu a pena! Confesso que não tentei o pooling das filas (talvez eu não tenha entendido direito como fazer) mas tenho agora um novo problema:
Não pude utilizar ArrayBlockingQueues porque eu precisei de uma coleção. Neste caso, só aproveitei a lógica de sincronização.
Porém, apesar de ter criado uma variável ReentrantLock, estou obtendo erro de Concurrent Modification Exception ao percorrer a coleção que, acredito, está sendo alterada por outra thread.
Como faço para utilizar a diretiva de imparcialidade do ReentrantLock? Isto resolveria o meu problema?
ArrayBlockingQueue possui dois métodos para fazer pooling, pool() para remover e offer() para inserir. Da uma lida no javadoc a respeito desses métodos.
Não entendi sua pergunta, você quer um lock que possua algum critério de qual thread ganha o lock em caso de contenção? Se for isso provavelmente não resolverá teu problema.
CME ocorre quando você modifica uma collection sem ser pelo iterator em questão, não necessáriamente de outra thread. O nome é pessimo porque remete a idéia de múltiplas threads. Por exemplo:
List l = .... //lista com 10 items
Iterator t = l.iterator();
l.remove(3);
t.next(); // vai lançar CME.