🚀 go-pugleaf

W dniu wtorek, 24 stycznia 2017 13:40:08 UTC+1 użytkownik Borneq napisał:
> W wątku chcę wypełniać, w pętli w głównym czytać i kasować. Czy vector i 
> map są bezpieczne wątkowo?

Nie

W dniu 24.01.2017 o 13:47, godek.maciek@gmail.com pisze:
> W dniu wtorek, 24 stycznia 2017 13:40:08 UTC+1 użytkownik Borneq napisał:
>> W wątku chcę wypełniać, w pętli w głównym czytać i kasować. Czy vector i
>> map są bezpieczne wątkowo?
>
> Nie
A co zamiast nich można użyć? A może użyć te struktury, tylko dostęp 
poprzez jakiś mutex?

W dniu wtorek, 24 stycznia 2017 14:15:07 UTC+1 użytkownik Borneq napisał:

> >> W wątku chcę wypełniać, w pętli w głównym czytać i kasować. Czy vector i
> >> map są bezpieczne wątkowo?
> >
> > Nie
> A co zamiast nich można użyć? A może użyć te struktury, tylko dostęp 
> poprzez jakiś mutex?

Można użyć muteks/sekcję krytyczną. Do prostych zastosowań powinno wystarczyć
(Generalnie w C++ obowiązuje zasada, żeby nie płacić za to, czego się nie używa)

W dniu 24.01.2017 o 14:33, godek.maciek@gmail.com pisze:
> Można użyć muteks/sekcję krytyczną. Do prostych zastosowań powinno wystarczyć
> (Generalnie w C++ obowiązuje zasada, żeby nie płacić za to, czego się nie używa)

https://pl.wikibooks.org/wiki/POSIX_Threads/Synchronizacja_mi%C4%99dzy_w%C4%85tkami/Mutexy

Czy muteksy to mają być obiekty globalne? Wolałbym by były to pola 
obiektu ale czy wątek będzie miał dostęp do obiektu? Procedura wątkowa 
nie może być obiektowa (co najwyżej statyczna), a może obiekt this 
podawać jako parametr?

W dniu wtorek, 24 stycznia 2017 15:13:17 UTC+1 użytkownik Borneq napisał:

> > Można użyć muteks/sekcję krytyczną. Do prostych zastosowań powinno wystarczyć
> > (Generalnie w C++ obowiązuje zasada, żeby nie płacić za to, czego się nie używa)
> 
> https://pl.wikibooks.org/wiki/POSIX_Threads/Synchronizacja_mi%C4%99dzy_w%C4%85tkami/Mutexy
> 
> Czy muteksy to mają być obiekty globalne?

To, czy obiekt jest "globalny", czy nie, to kwestia tylko i wyłącznie
organizacji oprogramowania. Na pewno nie ma powodów, żeby muteksy
były globalnymi obiektami.

> Wolałbym by były to pola 
> obiektu ale czy wątek będzie miał dostęp do obiektu?

Jeżeli przekażesz mu referencję, to będzie miał dostęp.
W wątkach posixowych jest tak, że przy tworzeniu wątku
przekazujesz dodatkowy parametr -- wskaźnik -- który zawiera
to, co chcesz, żeby zawierał.

> Procedura wątkowa 
> nie może być obiektowa (co najwyżej statyczna), a może obiekt this 
> podawać jako parametr?

Nie siedzę w C++ na tyle głęboko, żeby stwierdzić, czy to dobra praktyka,
ale na ile rozumiem sprawę, to co nazywasz "procedurą obiektową"
(rozumiem, że chodzi o metodę klasy), to zwykła funkcja, która przyjmuje
implicite dodatkowy parametr "this", toteż wydaje mi się, że sprawę
powinno załatwić odpowiednie rzutowanie (choć podejrzewam, że użytkownikom
C++ takie rozwiązanie może nie podchodzić, i pewnie są jakieś C++-owe
biblioteki, które to wszystko opakowują).

Na przykład takie coś:

pthread_t thread;
pthread_create(&thread, NULL, &MojaKlasa::metodaWKtorejUzywamThis, (void *) adresObiektuMojejKlasy)

On 1/24/2017 14:15, Borneq wrote:
> W dniu 24.01.2017 o 13:47, godek.maciek@gmail.com pisze:
>> W dniu wtorek, 24 stycznia 2017 13:40:08 UTC+1 użytkownik Borneq napisał:
>>> W wątku chcę wypełniać, w pętli w głównym czytać i kasować. Czy vector i
>>> map są bezpieczne wątkowo?
>>
>> Nie
> A co zamiast nich można użyć? A może użyć te struktury, tylko dostęp
> poprzez jakiś mutex?

Mozesz przyjrzec sie Intel Threading Building Blocks (TBB; licencja 
Apache 2.0) -- posiada concurrent container classes:
https://github.com/01org/tbb
https://www.threadingbuildingblocks.org/

Uwaga: Nie nalezy sie spodziewac cudow / darmowego lunchu (dotyczy to 
tym bardziej standardowych kontenerow recznie opakowanych mutexami -- 
t.j., "a serial container with a lock around it" bedzie jeszcze bardziej 
kosztowny i moze Ci zserializowac aplikacje, brutalnie mordujac wszelkie 
potencjalne zyski z wielowatkowosci; ale nawet lock-free nie jest za 
darmo, CPU i cache i tak musza synchronizowac dostepy do pewnego stopnia 
dla poprawnosci, a synchronizacja kosztuje):

"Notice that highly-concurrent containers come at a cost. They typically 
have higher overheads than regular STL containers. Operations on 
highly-concurrent containers may take longer than for STL containers. 
Therefore, use highly-concurrent containers when the speedup from the 
additional concurrency that they enable outweighs their slower 
sequential performance."

Tutaj masz containers:
https://software.intel.com/en-us/node/506169
https://software.intel.com/en-us/node/506079

concurrent_vector:	
https://software.intel.com/en-us/node/506203
https://www.threadingbuildingblocks.org/docs/doxygen/a00046.html

Roznice w por. z std::vector: 
http://www.randomprogramming.com/2014/08/stdvector-vs-tbbconcurrent_vector-api-design/

Patrz tez:
https://software.intel.com/en-us/blogs/2008/07/24/tbbconcurrent_vector-secrets-of-memory-organization
https://software.intel.com/en-us/blogs/2009/04/09/delusion-of-tbbconcurrent_vectors-size-or-3-ways-to-traverse-in-parallel-correctly

concurrent_hash_map:
https://software.intel.com/en-us/node/506191

concurrent_unordered_map:
https://software.intel.com/en-us/node/506171

Pozdrawiam,
Matt