| Autor |
Mensagem |
|
|
Se seu dispositivo requer que a resposta seja enviada em no máximo 30 ms, eu diria que é necessário deixar só essa parte que recebe a requisição e envia uma resposta (qualquer que seja ela) em uma thread com a prioridade RealTime (as outras threads não devem usar essa prioridade).
Esse é um dos poucos casos em que é absolutamente necessário alterar a prioridade de uma thread.
Atenção! Atenção! Atenção! Essa thread deve fazer quase nada, exceto pelo fato de responder rapidamente à requisição do dispositivo. Qualquer regra de negócio, etc, deve ser feita fora dessa thread.
(Por que é que você não precisaria disso se sua thread ficasse escutando um socket ou esperando ler de um arquivo? É que nesses dois casos o Windows já eleva a prioridade da thread que está esperando ler de um socket, ou ler de um arquivo, para uma prioridade bem alta. Uma vez que o socket tenha sido lido ou o arquivo tenha sido lido, então a prioridade baixa automaticamente. Mas no caso de uma interface serial, isso não ocorre. )
|
 |
|
|
|
Trancado.
|
|
|
|
|
Trancado. Leia as normas do fórum.
|
|
|
|
|
http://www.guj.com.br/posts/list/143046.java
|
|
|
|
|
Vou trancar este tópico provisoriamente,por conta de um troll cujo nome não deve ser invocado.
|
|
|
|
|
http://www.ioplex.com/jespa.html
|
|
|
|
Você poderia fazer um comparativo entre várias metodologias ágeis, por exemplo (Scrum e outras). Obviamente você não vai incluir a XGH (Extreme Go Horse 
|
|
|
|
|
Bom, como aqui não é o Procon, nem o Reclame Aqui ou a Polícia Federal, vou trancar isto aqui e deixar a solução do caso às autoridades competentes. Não adianta reclamar aqui porque não temos poder nenhum de polícia.
|
|
|
|
Só para constar, eu acertei o título deste post para não ficar muito comprido. (Tirei aquele montão de pontinhos.)
É que há um bug no fórum que faz com que alguém que queira dar um "reply" na sua mensagem acabe tomando uma exceção que basicamente diz "o título ficou muito comprido para inserir a resposta no banco".
|
|
|
|
Collections.synchronizedMap encapsula seu Map em outro objeto que simplesmente põe um "synchronized" em cada acesso a esse mapa. É algo ingênuo e muito geral.
Isso tem mais ou menos o mesmo defeito da antiga classe Hashtable: ela simplesmente garante que a estrutura do Map não é corrompida por acesso multithread, mas não garante que seja eficiente acessar esse mapa por várias threads.
Se vocês olharem o pacote java.util.concurrent ( http://download-llnw.oracle.com/javase/6/docs/api/java/util/concurrent/package-summary.html ) , irão ver que há duas classes bem diferentes para o acesso concorrente a um Map: ConcurrentHashMap (que é o HashMap "turbinado") e ConcurrentSkipListMap (que é uma classe análoga a TreeMap, no sentido em que conserva os elementos ordenados, mas que funciona internamente de forma bem diferente. )
|
|
|
|
wolmirGarbin wrote:
Valeu sabichão se sabe tanto porque não usa o google pra pesquisar....
Aprenda a agradecer pela ajuda se quiser que alguel o ajude falo!
progjava wrote:
pq tem o forum pra isso e consegui a resposta , não tem como fazer!. Agora vc ta no lugar errado , ñ leu a pergunta, respondeu outra coisa, alem de ñ saber a resposta!! é brincadeira.
Esse Local é pra Programadores Avançados vlw !
Falta de educação é mato aqui no Brasil. Se eu tivesse o poder de dropar usuários, estaria dropando um agora mesmo. Trancando este tópico em um feriado chuvoso...
|
|
|
|
|
http://download-llnw.oracle.com/javase/6/docs/api/java/util/concurrent/ConcurrentHashMap.html#keySet%28%29
|
|
|
|
Marky.Vasconcelos wrote:Boa, mas a interface podia se chamar simplesmente Closable.
Isso tudo são syntax-sugars ou realmente houve alguma mudança na estrutura dos programas em Java?
Já existe uma interface Closeable:
http://download-llnw.oracle.com/javase/6/docs/api/java/io/Closeable.html
A Closeable, no Java 7, irá estender Autocloseable.
O que o Darcy não conseguiu é que as classes e interfaces do JDBC que tèm um método close() implementassem Autocloseable. (A propósito, elas também não implementam java.io.Closeable, principalmente porque a interface java.io.Closeable tem um método close que lança a exceção IOException, e o close do JDBC lança SQLException.
O close do Autocloseable irã lançar simplesmente Exception, o que é permitido pelo Java (você, ao estender uma interface, pode redefinir o método lançando uma exceção mais específica - por exemplo, se Autocloseable lança Exception, java.io.Closeable pode lançar IOException, e java.sql.Closeable (uma interface que não existe, aliás) poderia lançar SQLException, sem problemas.
Voltando à vaca fria: é claro que é um syntax sugar. Mas que economiza um bocado de esforço e ajuda a tornar seus programas mais corretos, ajuda.
|
|
|
|
|
Antes de chegar ao post 120, vou fechar isto aqui. Já entrou no terreno do mtguNokA3V7reyFlsfj4bfmx, ou do DPthJV60F8QkSIBmA3Ec, ou sei lá de quem se trate.
|
|
|
|
arthurminarini wrote:então o problema é que quando ela voltar ele vai estar no computador!
Quando ela voltar ela simplesmente vai dar um "chega pra lá" e olhar os emails atrasados que ela não pôde ver porque estava acompanhando a implantação - isso se ela não tiver o seu próprio notebook, é claro.
Acho que o problema, na verdade, é se ele não apagar direito o histórico do browser. Veja:
http://www.theregister.co.uk/2006/03/23/firefox_bug_engagement_split_rumpus/
|
|
|
|