Thread [RESOLVIDO]

isacmarques
(usa Debian)

Enviado em 06/03/2015 - 16:24h

Boa tarde.

Montei uma função em C++ que le uma UART e registra os dados no banco de dados tirei algumas duvidas com o Paulo
como segue o link abaixo

http://www.vivaolinux.com.br/topico/C-C++/Comunicacao-UART-beaglebone

Tudo funciona direitinho quando esta dentro da main() mas quando chamo ela em uma thread os dados são lidos no entanto quando ocorre o problema listado no link acima a mesma trava ou seja o tratamento que eu fiz só funciona dentro da main na thread ele trava, parecendo que eu não tratei falhas de comunicação nesta função.

Desde já agradeço a ajuda de vocês mais uma vez.

paulo1205
(usa Ubuntu)

Enviado em 06/03/2015 - 19:38h

Você está usando threads diferentes para ler coisas diferentes ao mesmo tempo?

A abordagem que eu mostrei depende de sinais, que são entes vinculados a processos, não a threads. Se você tem uma thread que define um alarme e outra que supostamente define ou desliga outro alarme, o que fora definido pela primeira thread é sobrescrito pelo da segunda, pois o processo só pode ter um alarme de cada vez. Além disso, se chega o sinal de alarme ao processo, ele pode ser despachado para qualquer uma das threads, sem que você tenha muita escolha sobre qual thread será interrompida por ele para tratá-lo.

Quando se programa com threads, o buraco sempre é um pouco mais em baixo.

O que você pode fazer? Depende das suas necessidades. Eu pensei em algumas opções, listadas abaixo em ordem aproximadamente crescente de dificuldade, que podem ou não satisfazer suas necessidades.

Opção 1: usar diferentes processos, em lugar de diferentes threads (nesse caso, os dados de um processo não serão compartilhados com os demais, a não ser que você manualmente use algum mecanismo de memória compartilhada ou memory mapped I/O).

Opção 2: usar um processo só e com uma thread só, descritores de arquivos com o flag O_NONBLOCK ligado (ver open() e fcntl()), e usar select(), poll() ou epoll() para identificar quais descritores tiveram atividades dentro do timeout especificado (nesse caso, a execução do processo pode ficar temporariamente suspensa durante o tempo de timeout).

Opção 3: adaptar a opção acima para trabalhar sempre com timeouts nulos na hora de invocar select(), poll() ou epoll(), de modo a paralisar o processo pelo menor tempo possível para esperar por eventos de E/S (se você quiser ter um timeout de cada canal de comunicação, terá de fazer essa contagem por conta própria).

Opção 4: adaptar a opção 2 para trabalhar com exatamente duas threads, sendo uma para cuidar de E/S, e outra para controlar tudo o que não depende de E/S (você tem de ter muito cuidado para sincronizar o acesso a dados que sejam comuns entre as duas threads; leia sobre mutexes).

Opção 5: trabalhar com uma thread para cada descritor onde ocorram operações de E/S, e select(), poll() ou epoll() em cada thread exclusivamente para testar o descritor associado a essa thread (note que o problema de sincronização de acesso a dados comuns pode ficar mais complexo na medida em que o número de threads aumenta).

paulo1205
(usa Ubuntu)

Enviado em 10/03/2015 - 13:55h

Você marcou o tópico como resolvido. Teria como dividir conosco qual foi a solução?

isacmarques
(usa Debian)

Enviado em 10/03/2015 - 14:17h

Boa tarde,

Desculpa na correria acabei não respondendo.

Optei pela primeira opção no momento, fiz dois processos depois vou estudar as outras opções e ver o que eu posso implementar para as futuras versões. Com dois processos funcionou corretamente.


Obrigado pela ajuda.