Claudio Brotto

Larry Osterman ha concluso alcuni giorni fa la sua sa serie di post sulla programmazione concorrente.

Una serie davvero molto interessante ed istruttiva: al di là dei suoi "principles of concurrent programming", che vengono riassunti nell'ultimo post, ci sono diversi spunti di riflessione e, almeno per quel che mi riguarda, di studio.

Per esempio mi sono annotato un ripasso del Richter, sezione "Gestione Memoria", capitolo "Heap".

Come illustrato nel post # 11, l'allocazione di memoria da uno heap può essere o meno serializzata, e questo dipende dai flag di creazione dello heap stesso.

A meno di non utilizzare uno heap apposito, questo codice C++:

richiede i servizi dello heap primario del processo, che è serializzato. Ogni allocazione (e deallocazione) comporta l'acquisizione e il rilascio di una sezione critica, al fine di garantire la consistenza della struttura dello heap stesso.

Ovviamente se abbiamo la certezza assoluta che un solo thread alla volta possa utilizzare lo heap, nulla ci vieta di crearne uno ad-hoc rinunciando alla funzionalità di serializzazione delle allocazioni, e di sovrascrivere l'operatore new di una classe in modo che gli oggetti relativi non vengano allocati nello heap principale, ma in quello che abbiamo creato allo scopo.

Non c'è dubbio che queste siano ottimizzazioni abbastanza ... spinte, che diventano trascurabili se poi, magari, il nostro software accede al disco in modo pessimizzato.

Ma vale comunque la pena di sapere che cosa succede, non fosse altro per la curiosità di scavare nei meccanismi del sistema.