[quote=saoj]
Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.[/quote]
Uma vez eu vi essa frase escrita em um banheiro, abaixo tinha algo escrito assim: “O que você quer dizer com isso? você é burro?” eu acho que ele era um dos 10 tipos que não entende binário… 
[quote=André Fonseca][quote=saoj]
Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.[/quote]
Uma vez eu vi essa frase escrita em um banheiro, abaixo tinha algo escrito assim: “O que você quer dizer com isso? você é burro?” eu acho que ele era um dos 10 tipos que não entende binário… [/quote]
Com certeza! 
[quote=Homero Damico][quote=Giulliano][quote=saoj]
Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.[/quote]
e os outros 8 tipos ?!?!?!?1[/quote]
saoj 1 x 0 Giulliano[/quote]
Ptz Giulliano não acredito que você caiu nessa velho. Você não é um nerd de verdade?
Engraçado perceber o que 6h por anos faz diferença…
Calculando como saoj desprezando os anos bisextos dá 194.184 anos a mais que o calculo correto com bissexto…
pô…essa piada é péssima hein…hauhauhauahuhaa…
mas valeu a intenção…
Então ela era 01 tipo que não entende binário, porque o outro entende.
Se a variável do tipo long estiver em um endereço que não é múltiplo de 8, o que não costuma ocorrer porque o JIT tenta deixá-la em um endereço múltiplo de 8, isso poderia ocorrer sim, mas o correto é usar java.util.concurrent.AtomicLong se você estiver realmente preocupado com isso. As CPUs modernas, mesmo trabalhando em modo de 32 bits, não costumam recuperar dados da memória em pedaços menores que 64 bits, mesmo que você não perceba isso ao nível da linguagem de máquina.
[quote=thingol][quote]
Como a maioria dos CPUs são 32-bits, set e get de variáveis do tipo long podem em teoria dar problemas de race condition em Java. Alguém sabe mais detalhes sobre isso?
[/quote]
Se a variável do tipo long estiver em um endereço que não é múltiplo de 8, o que não costuma ocorrer porque o JIT tenta deixá-la em um endereço múltiplo de 8, isso poderia ocorrer sim, mas o correto é usar java.util.concurrent.AtomicLong se você estiver realmente preocupado com isso. As CPUs modernas, mesmo trabalhando em modo de 32 bits, não costumam recuperar dados da memória em pedaços menores que 64 bits, mesmo que você não perceba isso ao nível da linguagem de máquina.
[/quote]
A especificação do Tiger fala para vc usar volatile sempre que um thread altera e outro lê a variável, caso contrário cada um terá o seu próprio cache de variáveis e um não vai ver a mudança que o outro fez. Se não estou enganado esse cache acontece no registers da CPU, logo se vc tem apenas uma CPU esse problema NUNCA vai acontecer e vc não precisaria usar volatile. Isso porque sempre que entra um novo thread o contexto (cache) é substituído pelo novo contexto do thread que está entrando. Se vc tem duas CPUs e cada thread está rodando numa CPU então vc pode ter problemas sérios, uma vez que vc tem agora 2 caches distintos.
A questão do long é que independente do cache pode haver um context switch no meio de um get ou set, uma vez que é impossível ler 64-bits atomicamente num único tick do clock. Se isso acontece, a JVM garante ou não a integridade da variável? Nunca soube, acredito que sim, mas tb não sei como. 
[quote=ddduran][quote=Homero Damico][quote=Giulliano][quote=saoj]
Só a 10 tipos de pessoas no mundo. Os que entendem computação e os que não entendem.[/quote]
e os outros 8 tipos ?!?!?!?1[/quote]
saoj 1 x 0 Giulliano[/quote]
Ptz Giulliano não acredito que você caiu nessa velho. Você não é um nerd de verdade? :P[/quote]
Poxa… tb não acredito… hehehe