W dniu sobota, 22 czerwca 2013 10:42:57 UTC+2 użytkownik Bronek Kozicki napisał:
> On 20/06/2013 11:35, firr kenobi wrote:
>
> > czy najbardziej podstawowy z tych elementali
>
> > (jak mniemam mutex)
>
>
>
> Najbardziej podstawowy z elementów synchronizacji jest nie mutex, ale
>
> atomowa flaga (test-and-set, http://en.wikipedia.org/wiki/Test-and-set ).
>
>
nie jestem przekonany czy taka atomowa
operacja jest wogole potrzebna

dla przykladu

int lock = 0;

bool acquire()
{
if(!lock) { lock++; return true; }
else return false;
}

void thread1
{
if(acquire()) { ........... }
}

void thread2
{
if(acquire()) { ........... }
}

w takim kodzie gdyby w obu watkach
" if(!lock) lock++; " wystapilo co do cyklu rownoczenie (o ile cos takiego jest
mozliwe )
to mozna powiedziac ze oba watki przeszlyby
przez locka - ale gdyby nie robic lock+= tylko
przypisanie lock=thread_id to albo bylby jakis
wybuch kosci pamieci albo lock zapisalby sie jedna z wartosci wtedy mozna to
sprawdzic w kazdym acquire, jeden wycofac a drugi przepuscic
i chyba by działało

do góry

On Sat, 22 Jun 2013 09:42:57 +0100, Bronek Kozicki <b...@s...net>
wrote:

>On 20/06/2013 11:35, firr kenobi wrote:
>> czy najbardziej podstawowy z tych elementali
>> (jak mniemam mutex)
>
>Najbardziej podstawowy z elementów synchronizacji jest nie mutex, ale
>atomowa flaga (test-and-set, http://en.wikipedia.org/wiki/Test-and-set ).
>
>
>B.

Najbardziej podstawowym elementem synchronizacji jest semafor
Dihjstry. Podstawowym, albowiem przy jego pomocy mozna skonstruowac
wszystkie inne.

Tutaj jest do sciagniecia ksiazka na temat semaforow (bardzo dobra)

http://www.cs.ucr.edu/~kishore/papers/semaphores.pdf

A.L.

do góry

On Sat, 22 Jun 2013 07:12:38 -0700 (PDT), firr
<p...@g...com> wrote:

>>
>nie jestem przekonany czy taka atomowa
>operacja jest wogole potrzebna
>
>dla przykladu
>
>int lock = 0;
>
>bool acquire()
>{
> if(!lock) { lock++; return true; }
> else return false;
>}


To rozwiazanie nei dziala

A.L.

do góry

ale to drugie moglo by działac - cos w stylu

bool acquire(int therad_id, int* lock)
{
turn_interrupts_off();

if(*lock==0)
{
*lock = thread_id;
wait_some_junk_cycles(30);
restore_interrupts_on();
if(*lock!=thread_id) return false;
return true;
}
restore_interrupts_on();
return false;
}

lub podobnie (co do idei)

do góry

tutaj wait_some_junk_cycles jest dlatego
ze jesli miedzy if( lock == 0 ) a
lock = thread_id wstrzeli sie ze swoim ifem
drugi watek to trafi na 0 i sam zmieni
locka na swoje thread_id chwile po tym
pierwszym czyli sytuacja bedzie wygladac
tak:

0 0 0 0 0 0 0 0 150 150 150 150 160 160 160 160 ....

dalej sytuacja juz sie ustabilizuje wiec trzeba
tylko ew przeczekac te pare cykli
- trzebaby tez wylaczyc przerwania na te pare
cykli (lub ew sprawdzac ich wystapienie w tym
kawałku i rozbudowac procedure) - chodzi o to
ze czas miedzy if a set nie musi byc zerowy to
nie powinien byc jednak za dlugi
(to wszystko o ile nie pomylilem sie w rozkminkach
na ten temat - w kazdym razie mam pewne watpliwosci czy potrzeban jest operacja
atomowa,
zalezy zreszta jak kto rozumie atomowosc)

do góry

On Sat, 22 Jun 2013 09:07:11 -0700 (PDT), firr
<p...@g...com> wrote:

>ale to drugie moglo by działac - cos w stylu
>
>bool acquire(int therad_id, int* lock)
>{
> turn_interrupts_off();
>
> if(*lock==0)
> {
> *lock = thread_id;
> wait_some_junk_cycles(30);
> restore_interrupts_on();
> if(*lock!=thread_id) return false;
> return true;
> }
> restore_interrupts_on();
> return false;
>}
>
>lub podobnie (co do idei)

Wait for junk cycles tez nie dziala.

Gosciu, kup sobie jakas ksiazke i poczytaj. I jak po poczytaniu
bedziesz mial pytanie, to je zadaj. Poki co, zadajesz pytania w stanie
absulutnie, aptecznie sterylnej ignorancji.

Ta grupa to nei "uniwersytet latajacy"

A.L.

P.S. Jest znakomita ksiazka, po polsku

Podstawy programowania wspólbieznego i rozproszonego
Autor Ben Ari.

Do kupienia w empiku. Daj znac jak pzreczytasz

do góry

On Sat, 22 Jun 2013 09:21:38 -0700 (PDT), firr
<p...@g...com> wrote:

>tutaj wait_some_junk_cycles jest dlatego
>ze jesli miedzy if( lock == 0 ) a
>lock = thread_id wstrzeli sie ze swoim ifem
>drugi watek to trafi na 0 i sam zmieni
>locka na swoje thread_id chwile po tym
>pierwszym czyli sytuacja bedzie wygladac
>tak:
>
>0 0 0 0 0 0 0 0 150 150 150 150 160 160 160 160 ....
>
>dalej sytuacja juz sie ustabilizuje wiec trzeba
>tylko ew przeczekac te pare cykli
>- trzebaby tez wylaczyc przerwania na te pare
>cykli (lub ew sprawdzac ich wystapienie w tym
>kawałku i rozbudowac procedure) - chodzi o to
>ze czas miedzy if a set nie musi byc zerowy to
>nie powinien byc jednak za dlugi
>(to wszystko o ile nie pomylilem sie w rozkminkach
>na ten temat - w kazdym razie mam pewne watpliwosci czy potrzeban jest operacja
atomowa,
>zalezy zreszta jak kto rozumie atomowosc)

Nonsens.

A.L.

do góry

W dniu sobota, 22 czerwca 2013 19:09:10 UTC+2 użytkownik A. L. napisał:
> On Sat, 22 Jun 2013 09:07:11 -0700 (PDT), firr
>
> <p...@g...com> wrote:
>
>
>
> >ale to drugie moglo by działac - cos w stylu
>
> >
>
> >bool acquire(int therad_id, int* lock)
>
> >{
>
> > turn_interrupts_off();
>
> >
>
> > if(*lock==0)
>
> > {
>
> > *lock = thread_id;
>
> > wait_some_junk_cycles(30);
>
> > restore_interrupts_on();
>
> > if(*lock!=thread_id) return false;
>
> > return true;
>
> > }
>
> > restore_interrupts_on();
>
> > return false;
>
> >}
>
> >
>
> >lub podobnie (co do idei)
>
>
>
> Wait for junk cycles tez nie dziala.
>

dlaczego ?

(reszty nie skomentuje bo zbyt prymitywne)

do góry

On Sat, 22 Jun 2013 10:42:34 -0700 (PDT), firr
<p...@g...com> wrote:

>
>
>dlaczego ?
>

Niestety, ja nie mam ani czasu, ani checi ani motywacji zeby ci
udzielac wykladow. Zwlaszcza ze pytanie jest w stylu "dlaczego pole
kola to pi-er-kwadrat a nei pi-kwadrat-er"

Juz napisalem: ta grupa to nie uniwersytet. Kup ksiazkie i poczytaj

>(reszty nie skomentuje bo zbyt prymitywne)

Prymitywne - co? Ze odeslalem cie do ksiazki?

A.L.

do góry

W dniu sobota, 22 czerwca 2013 19:49:03 UTC+2 użytkownik A. L. napisał:
> On Sat, 22 Jun 2013 10:42:34 -0700 (PDT), firr
>
> <p...@g...com> wrote:
>
>
>
> >
>
> >
>
> >dlaczego ?
>
> >
>
>
>
> Niestety, ja nie mam ani czasu, ani checi ani motywacji zeby ci
>
> udzielac wykladow. Zwlaszcza ze pytanie jest w stylu "dlaczego pole
>
> kola to pi-er-kwadrat a nei pi-kwadrat-er"
>
>
>
> Juz napisalem: ta grupa to nie uniwersytet. Kup ksiazkie i poczytaj
>
>
>
> >(reszty nie skomentuje bo zbyt prymitywne)
>
>
>
> Prymitywne - co? Ze odeslalem cie do ksiazki?
>
>

prymitywne jest nieststy calosciowe podejscie
kolegi polegajace na tym ze kolega nie przeczytal
i nie zrozumial a udziela mi porad -- niemozebnie
mnie to wnerwia bo nie mam czasu na takie gadki
szmatki

do góry