Ok. Mulțumesc, Daniel!<div><br></div><div>Darius <br><br><div class="gmail_quote"><div dir="ltr">On Thu, 15 Mar 2018, 10:36 am Daniel Baluta, <<a href="mailto:daniel.baluta@gmail.com">daniel.baluta@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2018-03-15 2:52 GMT+02:00 Darius-Florentin Neatu <<a href="mailto:neatudarius@gmail.com" target="_blank">neatudarius@gmail.com</a>>:<br>
> Mulțumesc pentru raspunsuri!<br>
><br>
> @Robert<br>
> Stiu ca se poate declara in alta parte, dar am cateva argumente impotriva.<br>
> 1. Daca alocam global/static, vom avea nevoie de un mecanism de<br>
> sincronizare. Atunci absolut toate operatiile (incepand cu parsarea) s-ar<br>
> desfasura sincron.<br>
> 2. Daca alocam pe heap, acelasi lucru: daca folosesc parametrul GFP_KERNEL<br>
> procesul poate fi intrerupt (si nu vreau), iar daca bag alocarea intr-un<br>
> context atomic, din nou limitez paralelismul.<br>
> Prefer stiva si pentru ca este mai rapida.<br>
><br>
> Asa cum mi-am gandit eu implementarea, in sectiunea critica am doar accesul<br>
> efectiv in lista, celelalte rezultate (ex. valoarea inserata, nodul inserat<br>
> etc) fiind deja precalculate. In acest fel am o procesare minima in<br>
> sectiunea critica.<br>
><br>
> As vrea si un raspuns din partea responsabililor daca am procedat corect. Am<br>
> pus si cele de mai sus in README, ca sa justific modificarea acelei<br>
> dimensiuni.<br>
<br>
Salut Darius,<br>
<br>
Scopul temei este acomodarea cu API-ul de liste si cu mediul de<br>
dezvoltare.<br>
<br>
Toate solutiile propuse in acest thread sunt valide.<br>
<br>
thanks,<br>
daniel.<br>
</blockquote></div></div>