Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Lug Giu Mag Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Is good to be right

Poco prima del rilascio di DotNet 1.1 mi era stato assegnato un baco molto strano. In una situazione di multi-threading un pezzo di codice del dataset aveva cominciato a causare deadlocks. Siccome il baco non si manifestava nella versione 1.0, il baco era stato qualificato come regression. La cosa strana è che lo specifico pezzo di codice non era mai stato modificato tra la versione 1.0 e la versione 1.1. Cos'era successo: il baco era già li, ma ben nascosto. A causa della modifica dell'algoritmo della garbage collection il baco aveva cominciato a manifestarsi. Morale della favola: il multi-threading tende ad allontanare nello spazio tempo causa ed effetto, tocca guardare molto più lontano del solito.

Considerando il fatto che si è verificato un episodio del tutto analogo anche ieri ho cominciato a pensare ad un teorema:

Legge di Murphy-Paperino sul multithreading
È inutile cercare il deadlock nel pezzo di codice più ovvio; sarà solo fatica sprecata.

happy bug hunting!

-quack

Potrebbero interessarti anche:
Commenti (0):
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)