Pattern Observer + Threads

Olá. Por favor, não use as tags informativas como [Resolvido] para dizer algo óbvio, como [Dúvida].

Quanto à sua dúvida, acho que o padrão observer é interessante para que as threads notifiquem a tabela principal de seu status. As threads poderiam disparar um evento e, ao recebe-lo, você atualizaria o tablemodel.

Você pode fazer as threads pararem/religarem através de uma variável compartilhada.

ViniGodoy:

Olá. Por favor, não use as tags informativas como [Resolvido] para dizer algo óbvio, como [Dúvida].

Quanto à sua dúvida, acho que o padrão observer é interessante para que as threads notifiquem a tabela principal de seu status. As threads poderiam disparar um evento e, ao recebe-lo, você atualizaria o tablemodel.

Você pode fazer as threads pararem/religarem através de uma variável compartilhada.

Olá ViniGodoy,
Você teria algum exemplo desse tipo de funcionamento (uma thread enviado uma notificação via “evento” para outras threads usando o Pattern Observer)?
Obrigado!

Só esclarecendo. Threads não são classes. Threads não conseguem enviar algo para outras threads.

Se você quer que duas threads se comuniquem, precisa fazê-lo através de uma área compartilhada de memória, normalmente, uma synchronizedQueue.

Funciona assim:
a) Uma thread quer notificar algo, ela insere um dado na synchronizedQueue;
b) Outra thread está interessada na notificação, ela lê a synchronizedQueue.

Um dos exemplos clássicos é o algorítmo do produtor/consumidor. Uma thread gera algo que outra consome, e avisa sempre que é gerado.
Anexei um exemplo, está em C++ mas o funcionamento é igual em Java.

Eu sei que tenho um exemplo parecido em Java em algum lugar, anexo aqui assim que encontrar.

Preste atenção no seguinte:

• As classes de sensor geram os dados (no caso, representei isso gerando um número aleatório a cada 200ms), e simplesmente disparam esses dados para seus listeners (classe Processador);
• A classe do processador escuta os sensores e agrupa os dados recebidos numa fila. Quem faz a inserção na fila é a thread do sensor;
• A classe do processador lê os dados dessa fila e os processa. Quem faz a leitura é a thread do processador;

Como o acesso da fila é compartilhado pelas 3 threads, é necessário usar lock para garantir que apenas uma das thread esteja trabalhando sobre a fila (exclusão mútua).

Nesse padrão, o sensor é chamado de produtor (já que ele produz eventos) e o processador de consumidor (já que ele processa os eventos gerados).

ViniGodoy:

Só esclarecendo. Threads não são classes. Threads não conseguem enviar algo para outras threads.

Se você quer que duas threads se comuniquem, precisa fazê-lo através de uma área compartilhada de memória, normalmente, uma synchronizedQueue.

Funciona assim:
a) Uma thread quer notificar algo, ela insere um dado na synchronizedQueue;
b) Outra thread está interessada na notificação, ela lê a synchronizedQueue.

Um dos exemplos clássicos é o algorítmo do produtor/consumidor. Uma thread gera algo que outra consome, e avisa sempre que é gerado.
Anexei um exemplo, está em C++ mas o funcionamento é igual em Java.

Eu sei que tenho um exemplo parecido em Java em algum lugar, anexo aqui assim que encontrar.

Preste atenção no seguinte:

• As classes de sensor geram os dados (no caso, representei isso gerando um número aleatório a cada 200ms), e simplesmente disparam esses dados para seus listeners (classe Processador);
• A classe do processador escuta os sensores e agrupa os dados recebidos numa fila. Quem faz a inserção na fila é a thread do sensor;
• A classe do processador lê os dados dessa fila e os processa. Quem faz a leitura é a thread do processador;

Como o acesso da fila é compartilhado pelas 3 threads, é necessário usar lock para garantir que apenas uma das thread esteja trabalhando sobre a fila (exclusão mútua).

Nesse padrão, o sensor é chamado de produtor (já que ele produz eventos) e o processador de consumidor (já que ele processa os eventos gerados).

Obrigado ViniGodoy,
Deu pra ter uma noção (pena que não muita noção de C++).
Se encontrar o código java melhor ainda.
De qualquer forma, obrigado pelas dicas.

Achei. Estava aqui no meu trabalho.

Segue o exemplo. A classe Produtora produz e dispara um evento. Cada consumidor (Observer) pode ser registrado a um Produtor (Observable).
Cada consumidor tem sua própria lista de eventos, que é sincronizada manualmente (em blocos synchronized). O código poderia ser deixado mais simples se a classe de lista sincronizada do Java fosse utilizada (LinkedBlockingQueue).