> > troche pozastanawialem sie nad mt kontynuujac

> > to co juz sobie ustalilem pare czy parenascie miesiecy

> > temu (mam nadzieje ze rozwazania nie zawieraja bledow)

> >

> > wyglada mi na to ze o ile bezkolizyjnosc mozna by

> > implementowac tylko na rozdrobnionym poziomie

> > dostepu do poszczegolnych floatow czy intow to

> > nie jest to zbyt realistyczne bo raczej nie wystarczy

> >

> > potrzebne sa bitowe klucze (loki) zamykajace na raz

> > spojnie cale struktury; mozna by probowac pokusic sie

> > by lokowac wrecz 'sprzetowo' (cos jak odpowiednik

> > hardware'owych przerwan) wszystkie struktury i

> > tablice hurtem

> > (co byc moze wogole nie wymagaloby ingerencji

> > programisty w sensie pisania jakiegokolwiek kodu -

> > acz musialby miec swiadomosc ze watki beda mu

> > sprzetowo zwisaly przy konkurencyjnym dostepie

> > do struktur i tablic

> > - nie wiem dokladnie co by z tego wyszlo ale

> > pojawily by sie wydaje obecne problemy z

> > zakleszczeniami i race'ami, byc moze jednek udaloby sie

> > je rozwiazac na tym sprzetowym poziomie a moze nie

> > - ten model bylby podobny chyba do obecnego sposobu

> > zakladania lokow (znanego mi osobiscie glownie

> > z przeczytania 'pthreads primer' bo sam nie

> > pisalem prawie nic wielowatkowych programow) -

> > z tym ze nie byloby kodu bo loki zakladalyby sie

> > automatycznie

>

> problemem jest tez to ze cala duza tablica lokowala by

> sie hurtem (podzial na stale kawalki ktore mozna

> by polokowac osobno tez byc moze nie rozwiazuje problemu)

>

>

> ogolnie wydaje mi sie ze zakladanie bitowych kluczykow

> wybranym kawalkom danych jest byc moze bardziej wygodnym

> rozwiazaniem, np mozna pomyslec o lokowaniu danych

> calego modulu - to by sklanialo do dzielania danych

> na moduly w zwiazku z potrzebami wielowatkowosci

> i/ale trudno mi powiedziec czy byloby to moze dobrze

> czy zle

>

> jeszcze jedna uwaga: ten bitowy kluczyk lokujacy jakas

> strukture danych nie powinien byc raczej z musu blokiem

> (na ktorym zwisa odczyt czy przypisnie) czesto powinien

> on byc raczej informacja czy dane sa zalokowane czy nie

> tak by mozna to bylo podlaczyc do normalnego watkowego

> ifa, druga rzecz ten bitowy kluczyk powinien raczej

> dawac oddzielnie ijnformacje o tym czy dane sa przez

> kogos obcego obecnie zajete tylko do read tylko do write

> czy do obu

>

> trzebaby sie zastanowic teraz jak ew wygladaloby

> programowanie przy takim ukladzie i jak by bylo

>

>

w sumie jak zastanawiam sie jak ew mozna by zrobic/moglo by wygladac
odpalenie liczenia tablicy 1000x1000 (np zbioru mandelbrota) na tysiacu
watkow to mz mogloby to wygladac np tak - przy uzyciu normalnych srodkow
potrzebna jest tylko atomowa funkcja 'acquire' do testu czy flaga jest wolna
i jej ustawienia i funkcja 'newThread' do odpalenia nowego watku

typedef char lock;



tab [1000][1000];

lock tab_column_lock[1000];

void calculateColumn(int k)
{

//.... operacje na tab[k][...]
}


void main()
{

for(int i=0; i<1000;i++)
{
if(acquire(tab_column_lock[i]))
{
newThread( calculateColumn(i) );
}

}

}

chyba daloby sie to zrobic normalnymi srodkami i 'skalowaloby' sie to
na n procesorow - np dla dziesieciu procesorow na kazdym mw odpaliloby
sie po sto watkow po czym w miare wygasania tych watkow moc
dzielilaby sie na pozostale




--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl