Newsgroup: it.comp.programmare
Titolo: SINCRONIZZAZIONE - opinione

Preferite:
a) poche API abbastanza a basso livello e quindi poco specifiche con le
quali poter realizzare qualsiasi strumento di sincronizzazione o
b) varie API (come in Windows) specifiche per vari problemi?
IMHO, la soluzione B è più "pallosa" per chi deve realizzare il SO, ed è
poco versatile.
La soluzione a) va studiata con molta attenzione, ma potrebbe consentire
all'utente di gestire la sincronizzazione in modo facile e intuitivo
(intuitivo perchè gli oggetti verrebbero costruiti dall'utente).
Kiuhnm

 b) varie API (come in Windows) specifiche per vari problemi?
Se con "sincronizzazione" intendi le primitive di sincronizzazione tra
processi concorrenti, direi che la scelta migliore è una combinazione di A +
B. Ovvero: codifichi una coppia di primitive veramente elementari per il
mutex (tipo l'approccio P/V con un valore di 1 bit), e poi esprimi tutto il
resto (semafori a valor multiplo, code, memorie condivise, ecc.) tramite
questa coppia di primitive.
Ciao.
Marco Spedaletti

 memorie condivise, ecc.) tramite questa coppia di primitive.
Leggendo un tuo post precedente deduco che conosci anche Linux.
In Linux le API per la sincronizzazione sono simili a quelle di Windows?
Kiuhnm

 In Linux le API per la sincronizzazione sono simili a quelle di Windows?
No. In Windows ci sono, praticamente, tre tipi di primitive: mutex, semafori
e sezioni critiche. Su Linux esistono solo i semafori.
In particolare, ci sono due tipi di semafori:
    * System V R4 (semget/semop/semctl);
    * POSIX (sem_init/sem_wait/sem_post).
Sono funzionalmente eguali ma hanno interfacce diverse. I POSIX sono
decisamente più rapidi (circa 4 volte rispetto al SVR4).
Ti consiglio la lettura di
http://www-106.ibm.com/developerworks/linux/library/l-rt5/
che è molto istruttiva, in termini di confronto.
Ciao.
Marco Spedaletti

 che è molto istruttiva, in termini di confronto.
Ho letto l'articolo e mi ha colpito il fatto che le sezioni critiche in
WinXP siano peggiorate (280%!)
Inoltre non riesco a capire perchè le sezione critiche sono più veloci dei
mutex.
Non "potrebbero" avere la stessa efficienza?
A quanto pare Windows chiama delle funzioni kernel per gestire i mutex. Che
bisogno c'è?
Se un contatore si trova nella memoria globale può essere tranquillamente
usato come Mutex da più processi utilizzando le apposite istruzioni hardware
((LOCK prefix), xchg, xadd, ecc...).
Comunque il problema principale, nel mio caso, è quello di gestire la
sincronizzazione in un Quasi-RealTime OS.
Un thread con priorità maggiore dovrebbe riuscire ad acquisire un Mutex
anche se questo appartiene già a un thread di priorità inferiore.
Mi pare un problema di difficile soluzione...(almeno rendendo la cosa
trasparente ai programmi).
Kiuhnm

mutex. 
Perche` non obbligano a switchare tra user-mode e kernel-mode, come ho
scritto in una recente risposta su icpw32.

 anche se questo appartiene già a un thread di priorità inferiore.
Il problema dei mutex è che possono causare una "inversione di priorità"
(cioè un processo a priorità maggiore viene bloccato da uno a priorità
minore). Per evitarlo è necessario che lo scheduler conosca la politica
d'uso dei mutex per stabilire i suoi protocolli ed evitare questo. In ogni
caso ti consiglio questi links:
MarteOS (un piccolo sistema operativo realtime embedded):
http://marte.unican.es/
What is a Real-Time System?:
http://www.cs.pitt.edu/~manas/courses/2510/RealTime.pdf
Ciao.
Marco Spedaletti

 
http://www.cs.pitt.edu/~manas/courses/2510/RealTime.pdf
Grazie per i link. Adesso mi accingo a leggere RealTime.pdf
Kiuhnm

 mutex. Che bisogno c'è?
la parola chiave qui è "non-busy waiting". Devi segnalare in qualche 
modo allo scheduler che ti metti in attesa. Tutto il resto si può fare 
(e viene fatto) con le varie Interlocked*
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 non ci dovrebbero essere problemi.
uh, č il principio su cui si basano le system call, non ti pare?


 Su Linux esistono solo i semafori.
se si parla di IPC, sì. Ma i POSIX thread hanno molte altri oggetti 
decisamente più vivaci


 (e viene fatto) con le varie Interlocked*
Vuoi dire che le sezioni critiche non mettono in pausa un processo, ma usano
il polling???
Kiuhnm

 b) varie API (come in Windows) specifiche per vari problemi?
c) lock-free OS
Forse seguirò quest'ultima strada: difficile, ma innovativa e attraente...
Kiuhnm




 mutex. Che bisogno c'č?
la parola chiave qui č "non-busy waiting". Devi segnalare in qualche
modo allo scheduler che ti metti in attesa. Tutto il resto si puň fare
(e viene fatto) con le varie Interlocked*
---
Tu mi dici che il motivo č che deve segnalare allo sched. ecc..., quindi
significa che segnalare (e quindi usare WaitForSingleObject) equivale ad
appoggiarsi al Kernel, giusto?
E allora, visto che le sezioni critiche *non* si appoggiano al Kernel, č
lecito chiedere se esse siano realizzate con il polling, no? (la domanda era
comunque ironica, dato che il polling non mi sembra molto efficiente).
Richter afferma (cosě hanno detto) che le sezioni critiche non eseguono
codice in "kernel mode" (terminologia forse un po' ambigua) e quindi sono
diverse dai Mutex.
Perchč???
Kiuhnm

 e quindi sono diverse dai Mutex. Perchè???
probabile che dica "in molti casi non richiedono di", piuttosto che 
escludere del tutto la possibilità. Non ti fidare troppo del "sentito 
dire", al terzo passaggio la frase riportata potrebbe già dire tutto il 
contrario


 attraente...
Delusione: ho letto una ventina di Paper e l'unico promettente riguarda una
proposta hardware.
Purtroppo il problema è molto complicato. I lock (includendo semafori,
mutex, ecc...) sono poco efficienti. I programmatori sono stati da molto
tempo abituati a usare lock nei loro programmi multithreading semplicemente
perchè non sono mai esistite alternative (efficienti). Gli esempi di OS
lock-free sono 2 o poco più e tutti risultano limitati a poche strutture
(liste, code, stack, ecc...).
Speranza: adesso basta leggere...vediamo che cosa riuscirò a inventarmi 'sta
volta!
(senza dimenticare che sto programmando su processori x86 *non* dotati di
forti primitive (tipo CAS2, MWCAS, ecc...)...chissà, forse il Pentium 4 e/o
l'Athlon XP hanno introdotto qualcosa di utile.....mmh........)
Kiuhnm