🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.comp.lang.asm
Article #2050

Re: ‘lock–free’ aka odżywianie grupy asemblerowców :-)

#2050
From: minięty czas
Date: Mon, 11 Jan 2010 10:16
83 lines
5304 bytes
onegdaj ‟Michoo” rzecze:
> minięty czas pisze:
>> onegdaj ‟Bogdan (bogdro)” rzecze:
>>>>     czy  instrukcja ‘compare  and  set’ (oraz  wszystkie  podobne),
>>>> to  nie jest instrukcja blokująca?   co z tego, że sama w sobie nie
>>>> blo- kuje, jeśli  i tak  oparte  na  niej algorytmy używają jej jako
>>>> blokera? algorytmy, które  zwą siebie mianem ‘lock—free’…   to chyba
>>>> tylko zwykła reklama.
>>>  Sam sobie odpowiadasz: "co z tego, że sama w sobie nie blokuje". Ta
>>> instrukcja jest nieblokująca, dlatego należy ją poprzedzić prefiksem
>>> LOCK. Wtedy, oczywiście, staje się blokująca.
>>>  Swoją drogą, nie masz na myśli "compare and exchange"?
>> 	ale nie o to dokładnie.
>> 	wiadomo, że prefiks “lock” blokuje procesor (czy cokolwiek)
>> 	·wewnętrznie·, ale mam na myśli typowe zastosowania tej instrukcji
>> 	(tak, ‘and exchange’). ta instrukcja w algorytmach ‘lock–free’
>> 	występuje zwykle jako warunek pętli, co wydaje się, że działa tak samo
>> 	jak każdy inny mechanizm blokowania.
> Typowe przykłady zastosowania ssą ;) (Tzn zazwyczaj robi się na tym taki
> mutex z aktywnym oczekiwaniem.)
> 
> Rozważmy kolejkę fifo służącą do przekazywania komunikatów między n
> producentami a k konsumentami:
> standardowo)
> blokujesz dostęp do kolejki
> wstawiasz element
> odblokowujesz dostęp
> 
> blokowanie jak sama nazwa wskazuje uniemożliwia innym równoległy dostęp,
>   jeżeli zderzą się 4 procesy to 1 wejdzie do sekcji krytycznej a reszta
> pójdzie spać (co jest drogie - zmiana kontekstu)
> 
> w podejściu lock-free)
> próbujesz wstawić coś do kolejki
> jeżeli próba się nie powiodła to ją ponawiasz
> 
> cały czas nie blokujesz nikomu dostępu - jeżeli zderzą się 4 procesy to
> 1 zakończy akcję z sukcesem a reszta ponowi próbę w następnym cyklu a
> dzięki prefiksowi lock za każdym razem jednemu się powiedzie.
> 
> O ile dobrze pamiętam to jest to działające wstawianie do listy
> jednokierunkowej:
> 
> extern "C" int enqueue(void *item,void *queue)__attribute__((fastcall));
> 
> section .text
>          global enqueue
> ;edx - wskażnik na wskaźnik na kolejkę, ecx - wskaźnik na wstawiany
> element enqueue:
wskaźnik na adres pierwszego elementu kolejki. ;-)
>          mov eax,[edx]           ;[**]ładujemy adres aktualnego ogona
> pre:    mov [ecx],eax           ;[*]ustawiamy go jako poprzednika we
> wstawianym elemencie
>          lock cmpxchg [edx],ecx  ;staramy się podmienić wskaźnik na ogon
> listy
>          jne pre                 ;jak się nie powiodło to ponawiamy
>          próbę ret
> 
> koszt całości jest niewielki, mimo, że lock zaburza trochę przetwarzanie
> strumieniowe (blokada magistrali)
    raczej  nie  ma  gwarancji, że jednemu wątkowi się powiedzie w pier-
wszym podejściu, chyba że w doborze instrukcji i ich ułożeniu uwzględnić
docelową architekturę, by wydawało się, że dzięki jednoczesnemu przetwa-
rzaniu kilku instrukcji przetworzy je w jednym cyklu.
    to  co  powyżej  to  jest  właśnie  blokada  dostępu (czyli  tzw.
‘lock’), ale  przeniesiona  na  poziom instrukcji procesora architektury
‘cisc’, co nie oznacza, że automatycznie zawsze i w każdym przypadku ta-
ka  instrukcja  jest  wykonywana  bez dodatkowych kosztów, niewidocznych
dla  programu.   więc wydaje się, że odpowiedniejszą nazwą dla tego typu
algorytmów byłaby ‘mutex—free’, czyli pozbycie się blokowania uniwersal-
nego  na  rzecz  blokowania  wewnątrzprocesorowego.   jakby  zmierzanie
do  rozwiązań  typu ‘clean  box’, ale  w rzeczywistości  to  jest zwykłe
‘black box’… ;-)
    a o co mi tak naprawdę chodzi? :-)   tego można się dowiedzieć, zas-
tanawiając  się, kiedy ·nie· można  zastosować  instrukcji typu ‘compare
and  set’ i dlaczego —ale  nie  dlatego, że  przenosi  zbyt mało danych.
i jak by wyglądał taki algorytm na procesor ‘risc’…?
    „―it's very suspicious…   ―he's a garbage boy.   get relax.”
-- 
/ qo   |)    :@=N%_g=v=a=g_eD_e=c()=d=8! =%!gN@8'Re. w8in/ad
\    _x/ ,   ;h-%-a'hA'H4,X0'Xo~xo~xO,R`-%EXp01ITed: *-7/+eh
/    |    ng `-%__%--'__%--'__%--~__%--^%B`/$qV3r[o; &GooMee
L_._o_O_*_^_"_'_`_ -> http://thereis.notlong.com <- `L"EnOF"
Technical Details
Message-ID: <hietpm$h9g$1@news.mixmin.net>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.pionier.net.pl!feeder.erje.net!news.mixmin.net!not-for-mail
References: <hi7d3a$u60$1@news.mixmin.net> <hi7otf$793$1@inews.gazeta.pl> <hi7rnu$g3v$1@news.mixmin.net> <hidkec$as1$1@news.onet.pl>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!newsfeed.gazeta.pl!newsfeed.pionier.net.pl!feeder.erje.net!news.mixmin.net!not-for-mail
From: minięty czas <crav@surfy.net>
Newsgroups: pl.comp.lang.asm
Subject: Re: ‘lock–free’ aka
 odżywianie grupy
 asemblerowców :-)
Date: Mon, 11 Jan 2010 10:16:24 +0000 (UTC)
Organization: opRWTng
Message-ID: <hietpm$h9g$1@news.mixmin.net>
References: <hi7d3a$u60$1@news.mixmin.net> <hi7otf$793$1@inews.gazeta.pl> <hi7rnu$g3v$1@news.mixmin.net> <hidkec$as1$1@news.onet.pl>
Mime-Version: 1.0
Injection-Date: Mon, 11 Jan 2010 10:16:24 +0000 (UTC)
Injection-Info: news.mixmin.net; posting-host="c1636f81fee22411058317f0c2307260"; logging-data="17712"; mail-complaints-to="abuse@mixmin.net"
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit