[es] - Implementacija mutex-a

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Implementacija mutex-a

^{04.02.2009. u 18:55 - pre 185 meseci}

Pa mozda nije kernel mode implementacija a pride i "sece krivine"

, npr:

Citat:

For speed, Pthreads-w32 never checks the thread ownership of mutexes of type PTHREAD_MUTEX_NORMAL (or PTHREAD_MUTEX_FAST_NP) when performing operations on the mutex. It is therefore possible for one thread to lock such a mutex and another to unlock it.

U principu ako je pthread implementacija cisto intraprocess onda low-contention poredjenje sa windows mutexima nema smisla, onda je bolje porediti sa Win critical sections.

Citat:

Ivan Dimkovic: Medjutim, problem je sto malo koji projekat ima vremena da se developeri pozabave dubljom analizom performansi koda, koja bi ukljucila i analizu sinhronizacije izmedju threadova, pa je nekako "pravilo desne ruke" da se umesto mutex-a koristi critical section, pa cak i ako u nekim slucajevima ne donosi dobitke.

Ali slozices se da je to 'easy way out' isto koliko i mutexi, samo da se ne razmislja o problemu previse

. U situaciji kad imas 20 threadova koji u proseku provode 80% vremena cekajuci isti critical section/mutex, onda je to dobar povod da se task reprogramira i da se contention razresi adekvatno (recimo daljom paralelizacijom i defragmentacijom posla), medjutim istina jeste da ce retko ko da se pozabavi time.

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan, sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv… - Z.Đinđić

Odgovor na temu

Nedeljko
Nedeljko Stefanović

Član broj: 314
Poruke: 8632
*.dynamic.sbb.rs.

+2789 Profil

Re: Implementacija mutex-a

^{05.02.2009. u 11:13 - pre 185 meseci}

Citat:

mmix: Pa mozda nije kernel mode implementacija a pride i "sece krivine" ;), npr:

For speed, Pthreads-w32 never checks the thread ownership of mutexes of type PTHREAD_MUTEX_NORMAL (or PTHREAD_MUTEX_FAST_NP) when performing operations on the mutex. It is therefore possible for one thread to lock such a mutex and another to unlock it.

Pretpostavio sam tako nesto.

Smatram da u kodu dovolno vodim racuna o tome, tako da mi ta provera nije potrebna.

Citat:

Ivan Dimkovic: Na zalost, nemam sad vremena da pogledam Linux implementaciju pthread_mutex-a, ali me definitivno zanima zasto mislis da je ta implementacija brza od kriticnih sekcija na windows-u?

Ne mislim, nego me platform dependent resenja ne interesuju. QMutex lepo obmota kriticne sekcije na Windows platformi, na UNIX like platformi koristi mutex-e i super.

Nije bitno koji su zaključci izvučeni, već kako se do njih došlo.

Odgovor na temu

tosa
上海，中国

Član broj: 1811
Poruke: 1342
58.32.235.*

ICQ: 14293955
Sajt: https://github.com/milost..

+48 Profil

Re: Implementacija mutex-a

^{06.02.2009. u 06:23 - pre 185 meseci}

InterlockedXXX funkcije nisu skroz safe same po sebi, zbog reordering-a instrukcija, sto na nivou hardvera sto na nivou kompajlera.
Topli savet je da se koriste memory barrier-e u kombinaciji sa InterlockedXXX funkcijama da bi se dobilo ocekivano ponasanje na svim platformama.
Ovo je na nekim platformama prilicno ozbiljan problem ako se ignorise i tice se i thread safety-a i performansi koda (ako je neophodno, na primer,
upisivati u memoriju sekvencijalno).

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Implementacija mutex-a

^{06.02.2009. u 10:45 - pre 185 meseci}

Hmm, prvi put cujem za ovo, koliko je meni poznato Interlocked API upravo za to i sluzi.

Kako god da obrnes, interlocked operacija se na kraju svede na atomizaciju operacije unutar critical sekcije, koja na kraju zavrsi sa spinlockom kroz derivat XCHG instrukcije koja obezbedjuje memory barrier (takva je namerno po dizajnu i sprecava reordering), tako da ni kompajlerski ni hardverski reordering ne mogu da uticu na atomicnost interlocked api funkcije, kao sto ne mogu ni na critical sekcije i kernel wait objekte. Windows bar ne koristi cisto softverske locking paterne a sumnjam da i linux pati od toga.

Odgovor na temu

tosa
上海，中国

Član broj: 1811
Poruke: 1342
..w.sh.dynamic.163data.com.cn.

ICQ: 14293955
Sajt: https://github.com/milost..

+48 Profil

Re: Implementacija mutex-a

^{06.02.2009. u 18:38 - pre 185 meseci}

Potpuno si u pravu, i velika većina korisnika može da ignoriše moj komentar, ali radio sam na platformi gde je jedini oblik non-kernel sinhronizacije bio "ručno" upisivanje L2 keša.

Odgovor na temu

mmix
Miljan Mitrović
Profesorkin muz
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6042

+4631 Profil

Re: Implementacija mutex-a

^{06.02.2009. u 21:31 - pre 185 meseci}

Tek sad mi nije jasno, mozda gresim ali memory barrier posledica xchg instrukcije je dokumentovani requirement za implementaciju okolnog hardvera, tj posledica toga da bus mora biti zakljucan kad je LOCK aktiviran. A tehnicka dokumentacija za intelove cipove to direktno navodi na vise mesta, npr:

Citat:

When a memory operand is used with the XCHG instruction, the processor's LOCK signal is automatically asserted.

If a memory operand is referenced, the processor’s locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. (See the LOCK prefix description in this chapter for more information on the locking protocol.) This instruction is useful for implementing semaphores or similar data structures for process synchronization.

Znaci ne da blokira out-of-order execution i "sece" kroz L1/L2 kes i load/store reordering nego sece i kroz magistralu zbog multi-CPU platformi. Vi ili nesto niste dobro uradili ili hardver na kome ste radili ne podrzava LOCK signal na magistrali (sto mi je jos bizarnije).

Odgovor na temu