Linux, operazioni atomiche

[71104]

esiste su Linux qualche funzione analoga alle varie InterlockedXxx di Win32? in particolare mi servirebbero la InterlockedIncrement e la InterlockedDecrement (devo gestire un reference count in concorrenza), ma sarebbe gradita anche una InterlockedCompareExchange

[^TiGeRShArK^]

Originariamente inviato da 71104

Linux, operazioni atomiche

rm -rf /*
una vera BOMBA ATOMICA



P.S. notare quanto siano vicini sul tastierino numerico / e * e quanto è facile fare danni irreparabili quando si vuole fare rm -rf * e invece si fa rm -rf /*

X fortuna io al max ho fatto crontab -r al posto di crontab -e

[cionci]

Originariamente inviato da ^TiGeRShArK^

P.S. notare quanto siano vicini sul tastierino numerico / e * e quanto è facile fare danni irreparabili quando si vuole fare rm -rf * e invece si fa rm -rf /*

Basta usare una distribuzione che non ti fa loggare come root e non avrai problemi...

[cionci]

Cosa ti vieta di usare una semplice mutex ?

[^TiGeRShArK^]

Originariamente inviato da cionci

Basta usare una distribuzione che non ti fa loggare come root e non avrai problemi...

mmm..
ovviamente non ho mai provato..
ma se lanci rm -rf /* da utente non ti cancella lo stesso tutti i tuoi file? (dato che sono quelli su cui hai i permessi)
Non pensavo che se non hai i permessi adatti nella directory di partenza ti fallisce proprio l'esecuzione del comando..
solo che cmq non ci tengo a provare
ne faccio già abbastanza di casini con linux..
soprattutto con VI e con la mia tastiera mista italiano/inglese (nel senso di tastiera inglese col layout in italiano )

[cionci]

In effetti...il fatto che ricorra l'albero potrebbe creare un problemi alla home directory, ma questo non ti impedirebbe di ricreare nuovamente l'utente.

[^TiGeRShArK^]

Originariamente inviato da cionci

In effetti...il fatto che ricorra l'albero potrebbe creare un problemi alla home directory, ma questo non ti impedirebbe di ricreare nuovamente l'utente.

si... questo lo so ke l'utente lo puoi ricreare..
ma tutti i tuoi dati, ovvero tutti i files su cui hai il permesso di scrittura, li perdi o no se lanci rm -rf /* anke se non sei root?

Prova e fammi sapere per sicurezza

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

ne faccio già abbastanza di casini con linux..
soprattutto con VI e con la mia tastiera mista italiano/inglese (nel senso di tastiera inglese col layout in italiano )

Prova un editor umano, joe, che ha i comandi del vecchio e amatissimo WordStar (in buona parte poi adottati dalla Borland coi suoi Turbo*).

[^TiGeRShArK^]

fiko il wordstar
cmq ho appena provato e non c'è installato 'sto joe..
e non se me lo fanno installare qui al lavoro mi sa

cmq ancora non ho capito che succede se lancio rm -rf /* da utente....
braso tutti i dati su cui ho accesso in scrittura o no?

[ilsensine]

Originariamente inviato da 71104

esiste su Linux qualche funzione analoga alle varie InterlockedXxx di Win32? in particolare mi servirebbero la InterlockedIncrement e la InterlockedDecrement (devo gestire un reference count in concorrenza), ma sarebbe gradita anche una InterlockedCompareExchange

Rub..ehm prendi spunto da atomic_t nei sorgenti del kernel linux e le rispettive funzioni.

[cionci]

Ma siamo sicuri che in user space funzioni ugualmente ?

[cdimauro]

Originariamente inviato da ^TiGeRShArK^

fiko il wordstar
cmq ho appena provato e non c'è installato 'sto joe..
e non se me lo fanno installare qui al lavoro mi sa

Anche da me non c'era, ma l'ho fatto installare (in tutte le macchine: una trentina ): con joe sono DI GRAN LUNGA più produttivo che col VI.

[ilsensine]

Originariamente inviato da cionci

Ma siamo sicuri che in user space funzioni ugualmente ?

Sì sono dei semplici inline assembler con il prefisso "lock".

Ad es. mi è capitato di dover realizzare una classe tipo questa:

#ifdef __SMP_SUPPORT__
#define LOCK "lock "
#else
#define LOCK
#endif

class Atomic
{
private:
  volatile int m_val;
public:
...
  void Inc();
  int AddAndReturn(int val);
...
};

inline void Atomic::Inc()
{
  asm volatile(
    LOCK "incl %0"
    :"=m" (m_val)
    :"m" (m_val)
  );
}

inline int Atomic::AddAndReturn(int val)
{
  int old = val;
  asm volatile(
    LOCK "xaddl %0, %1;"
    :"=r"(val)
    :"m"(m_val), "0"(val)
  );
  return val+old;
}

[71104]

Originariamente inviato da cionci

Cosa ti vieta di usare una semplice mutex ?

si tratta del solito programma che sto facendo per l'università, quello col sorgente portabile per Windows e per Linux (l'ho quasi finito )

non so quanto "pesino" i semafori su Linux, ma certo è che su Win32 le InterlockedXxx sono molto più spedite di un mutex (cioè di un kernel object a tutti gli effetti).

[71104]

Originariamente inviato da ilsensine

Rub..ehm prendi spunto da atomic_t nei sorgenti del kernel linux e le rispettive funzioni.

e ti pareva che non ci stavano le funzioni già pronte
scrivere del codice assembly mi lega alla piattaforma: sicuramente non sarà richiesto che il programma giri su piattaforme diverse dagli x86 (penso che neanche lo farà andare su un processore a 64 bit), ma non so quanto piaccia al professore. per tenere il programma "leggero" potrei usare su Linux un pthread mutex al posto di un semaforo e su Win32 una sezione critica al posto di un mutex, ma in realtà non posso perché il reference count in questione deve essere condiviso tra processi.
conclusivamente alla mia prima esperienza di sorgente portabile non posso che dire la seguente cosa: GNU/Linux sarà anche na meraviglia, sarà l'emblema della prima utopia realizzata della storia, sarà rulez, sarà FOSS, sarà powa, sarà winzozz sucksz e tutto quello che vi pare; ma che sia "un sistema fatto dai programmatori per i programmatori" * non credo proprio -.-
a me Windows pare tecnologicamente molto più avanzato

* frase ricorrente che tra l'altro ripeteva spesso il mio prof di laboratorio di sistemi 1

[71104]

Originariamente inviato da cdimauro

Anche da me non c'era, ma l'ho fatto installare (in tutte le macchine: una trentina ): con joe sono DI GRAN LUNGA più produttivo che col VI.

non pensavo che qualcuno sulla faccia della Terra lo usasse veramente il VI... :|

una volta c'ho provato... sono stato costretto per l'esame di laboratorio di sistemi 1... ma credevo che fosse soltanto na roba didattica

[cionci]

Early Optimization is the root of all evil

Perché non usi le mutex su entrambi e festa finita ? Prima scrivi tutto e poi cerca di migliorarlo...

[71104]

Originariamente inviato da cionci

Perché non usi le mutex su entrambi e festa finita ? Prima scrivi tutto e poi cerca di migliorarlo...

ah mbe' se è per questo sono comunque costretto

come ho riassunto al post #15, credo che mi convenga usare il semaforo/mutex.

[^TiGeRShArK^]

Originariamente inviato da 71104

non pensavo che qualcuno sulla faccia della Terra lo usasse veramente il VI... :|

una volta c'ho provato... sono stato costretto per l'esame di laboratorio di sistemi 1... ma credevo che fosse soltanto na roba didattica

magari!
io ogni volta che edito un file sotto ssh sono costretto ad usare quello schifo...
e i primi tempi facevo tanti di quei danni che ci mettevano 10 minuti a riuscire a chiuderlo i miei colleghi che in teoria l'avrebbero dovuto sapere usare ... lo mandavo in LOOP

[ilsensine]

Originariamente inviato da 71104

scrivere del codice assembly mi lega alla piattaforma

Più al "compilatore" che alla "piattaforma", a meno che non devi scrivere anche per Sparc (nel qual caso basta che dai una occhiata nella directory asm-<processore> del kernel linux per avere la soluzione).

sicuramente non sarà richiesto che il programma giri su piattaforme diverse dagli x86 (penso che neanche lo farà andare su un processore a 64 bit), ma non so quanto piaccia al professore.

Quel codice gira perfettamente anche su x86-64.
Ok che l'asm è da evitare se possibile, ma hai trovato un ottimo esempio di utilizzo consigliato, che lo giustifica. Usando dei lock aggiungeresti un overhead assolutamente inutile.
Inoltre, leggendo la documentazione di "InterlockedIncrement":
http://msdn2.microsoft.com/en-us/library/ms683614.aspx
trovi scritto:

This function is implemented as an inline function using a compiler intrinsic where possible.

qundi forse anche queste sono implementate con inline asm.
Nota inoltre che

This function generates a full memory barrier (or fence) to ensure that memory operations are completed in order.

lo sfence non è necessario, a meno che non ti serva effettivamente.

posso che dire la seguente cosa: GNU/Linux sarà anche na meraviglia, sarà l'emblema della prima utopia realizzata della storia, sarà rulez, sarà FOSS, sarà powa, sarà winzozz sucksz e tutto quello che vi pare; ma che sia "un sistema fatto dai programmatori per i programmatori" * non credo proprio -.-

Non capisco questa tua affermazione, sono sistemi profondamente diversi, e anzi è incredibile che tutto sommato presentino molte similitudini.
Forse che portare del codice tra Windows e MacOS sarebbe più semplice?