Com\’è dura la professione!

10 luglio 2008

Database everywhere

Filed under: Programmazione — lbell @ 20:27

Con la disponibilità delle CPU multicore, le applicazioni saranno forzate a sfruttare il parallelismo, dividendo l’elaborazione fra più processi o thread, avendo il problema di gestire la concorrenza anche con la scelta delle strutture dati opportune. Scrivere programmi che gestiscano effettivamente il multi-threading non è facile.

Con l’architettura attuale di CPU l’operazione di lettura è molto più efficiente della scrittura dato che le modifiche alla memoria vengono propagate fisicamente a tutti i nodi, mentre la lettura può avvenire direttamente dalla cache locale. Per questo i task che devono accedere a parti di una struttura dati devono cercare di limitarne il blocco in modo esclusivo solo ad alcune zone per massimizzare il parallelismo e diminuire i punti di contenzioso. Alcune strutture che richiedono solo blocchi locali in accesso, come le liste linkate, si adattano meglio a questo paradigma, come spiegato da Herb Sutter in un articolo su Dr Dobbs di giugno. Per apportare una modifica ad un oggetto contenuto in una lista occorre bloccare l’accesso solo agli elementi contigui a quello selezionato. Altre strutture molto usate, come gli alberi bilanciati red black, durante una operazione di modifica possono dare origine ad una operazione di ribilanciamento, che nel caso peggiore potrebbe bloccare tutto l’albero, fino alla radice con ovvi problemi di performance.

Questi meccanismi di condivisione con la gestione della concorrenza attraverso il blocco di oggetti (o il loro versionamento) si utilizzano da tempo nella gestione di database dove si è curato l’accesso concorrente ai dati da parte di più applicazioni, con bassi costo di lettura, ed alti di modifica, con una serie di meccanismi specifici, transazioni, lock escalation, replicazioni di dati e viste materializzate, per esempio. Questi meccanismi hanno comportato anche il cambiamento del modo con cui sono scritti i programmi, attraverso l’uso cosciente e consapevole delle transazioni e dei livelli di isolamento dei processi. Probabilmente per sfruttare al meglio i multicore i programmi dovranno utilizzare strutture dati e librerie mutuate dall’esperienza ricavata dalla gestione delle basi di dati.

http://drdobbs.com/hpc-high-performance-computing/208801371

http://it.wikipedia.org/wiki/Albero_Red_Black

http://en.wikipedia.org/wiki/Multiple_granularity_locking

2 commenti »

  1. Questo è un’argomento molto interessante…
    Una struttura dati adatta in programmi multi-thread è la Skip List:
    http://en.wikipedia.org/wiki/Skip_list
    (è stata inserita anche in Java 6)

    A proposito di multicore, ho visto che stai leggendo ‘Programming Erlang’. Cosa ne pensi di questo linguaggio?

    Commento di Davide S. — 11 luglio 2008 @ 15:10 | Rispondi

  2. @ Davide:
    Erlang è un linguaggio di programmazione funzionale e dichiarativo e richiede un po’ di adattamento se provieni dal mondo C o Java. Non ho ancora visto personalmente programmi di una certa dimensione, ma so che viene utilizzato in sistemi mission critical ed è stato utilizzato per scrivere un server Jabber.
    Qui trovi maggiori informazioni.
    http://www.erlang.org/

    Commento di lbell — 14 luglio 2008 @ 18:46 | Rispondi


RSS feed for comments on this post. TrackBack URI

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

Blog su WordPress.com.

%d blogger cliccano Mi Piace per questo: