Motywacja: powód, dla którego rozważam to, że mój genialny kierownik projektu uważa, że ​​doładowanie jest kolejną zależnością i że jest okropne, ponieważ "jesteś od niego zależny" (próbowałem wyjaśnić jakość wzmocnienia, ale po pewnym czasie zrezygnowałem :( Mniejszym powodem, dla którego chciałbym to zrobić, jest to, że chciałbym nauczyć się funkcji języka c ++ 11, ponieważ ludzie zaczną pisać w nim kod.

1. Czy istnieje mapowanie 1: 1 między odpowiednikami #include<thread> #include<mutex>i boost?
2. Czy rozważyłbyś dobry pomysł, aby zamienić rzeczy boost na rzeczy z c ++ 11
   . Moje użycie jest prymitywne, ale czy są przykłady, kiedy std nie oferuje tego, co zapewnia wzmocnienie? Czy (bluźnierstwo) odwrotnie?

PS Używam GCC, więc są tam nagłówki.

Istnieje kilka różnic między Boost.Thread a standardową biblioteką wątków C ++ 11:

• Boost obsługuje anulowanie wątków, wątki C ++ 11 nie
• C ++ 11 obsługuje std::async , ale Boost nie
• Boost ma boost::shared_mutexblokadę dla wielu czytników / jednego zapisującego. Analogiczne std::shared_timed_mutexjest dostępne tylko od C ++ 14 ( N3891 ), natomiast std::shared_mutexjest dostępne tylko od C ++ 17 ( N4508 ).
• Limity czasu C ++ 11 różnią się od limitów czasu Boost (chociaż powinno to wkrótce zmienić się teraz Boost.Chrono zostało zaakceptowane).
• Niektóre nazwy są różne (np boost::unique_futurevs.std::future )
• Semantyka przekazywania argumentów std::threadróżni się od funkcji boost::thread--- Boost boost::bind, które wymagają kopiowalnych argumentów. std::threadzezwala na typy tylko std::unique_ptrdo przenoszenia, takie jak przekazywanie jako argumentów. Ze względu na użycie boost::bindsemantyki symboli zastępczych, takich jak_1 w wyrażeniach zagnieżdżonych powiązań, również może być inna.
• Jeśli nie jawnie wywołać join()lub detach()wówczas boost::threadoperator destructor i przypisanie wezwie detach()na obiekcie wątku niszczone / przypisany. W przypadku obiektu C ++ 11 std::threadspowoduje to wywołanie std::terminate()i przerwanie aplikacji.

Aby wyjaśnić kwestię parametrów tylko do przenoszenia, poniżej przedstawiono prawidłowy C ++ 11 i przenosi własność intz tymczasowego std::unique_ptrna parametr, w f1którym uruchamiany jest nowy wątek. Jeśli jednak użyjesz boost::thread, nie zadziała, ponieważ używa boost::bindwewnętrznie i std::unique_ptrnie można go skopiować. Istnieje również błąd w bibliotece wątków C ++ 11 dostarczonej z GCC, który uniemożliwia to działanie, ponieważ używa jej również std::bindw implementacji.

void f1(std::unique_ptr<int>);
std::thread t1(f1,std::unique_ptr<int>(new int(42)));

Jeśli używasz Boost, prawdopodobnie możesz stosunkowo bezboleśnie przełączyć się na wątki C ++ 11, jeśli twój kompilator to obsługuje (np. Najnowsze wersje GCC na Linuksie mają prawie kompletną implementację biblioteki wątków C ++ 11 dostępną w -std=c++0x trybie).

Jeśli Twój kompilator nie obsługuje wątków C ++ 11, możesz uzyskać implementację innej firmy, taką jak Just :: Thread , ale nadal jest to zależność.

std::threadjest w dużej mierze wzorowany na boost::thread, z kilkoma różnicami :

• semantyka, której nie można kopiować, mapowanie jednego uchwytu do jednego wątku systemu operacyjnego, jest zachowana. Ale ten wątek jest ruchomy, aby umożliwić powrót wątku z funkcji fabrycznych i umieszczenie go w pojemnikach.
• Ta propozycja dodaje anulowanie do boost::thread , co jest znaczną komplikacją. Ta zmiana ma duży wpływ nie tylko na wątek, ale także na pozostałą część biblioteki wątków C ++. Uważa się, że ta duża zmiana jest uzasadniona korzyściami.
  • Destruktor wątków musi teraz wywoływać anulowanie przed odłączeniem, aby uniknąć przypadkowego wycieku wątków podrzędnych, gdy wątki nadrzędne są anulowane.
  • Wymagany jest teraz jawny element odłączający, aby umożliwić odłączanie bez anulowania.
• Pojęcia dotyczące uchwytu wątku i tożsamości wątku zostały podzielone na dwie klasy (są w tej samej klasie boost::thread). Ma to na celu ułatwienie manipulacji i przechowywania tożsamości wątku.
• Dodano możliwość stworzenia identyfikatora wątku, który gwarantuje porównywanie się równy żadnemu innemu wątkowi możliwemu do połączenia ( boost::threadnie ma tego). Jest to przydatne w przypadku kodu, który chce wiedzieć, czy jest wykonywany przez ten sam wątek, co poprzednie wywołanie (konkretnym przykładem są rekurencyjne muteksy).
• Istnieją „tylne drzwi” umożliwiające uzyskanie rodzimego uchwytu wątku, tak aby klienci mogli w razie potrzeby manipulować wątkami przy użyciu podstawowego systemu operacyjnego.

To pochodzi z 2007 roku, więc niektóre punkty są już nieaktualne: boost::threadma native_handleteraz funkcję i, jak podkreślają komentatorzy, std::threadnie ma już anulowania.

Nie mogłem znaleźć żadnych znaczących różnic między boost::mutexi std::mutex.

Jest jeden powód, dla którego nie warto migrować do std::thread.

Jeśli używasz linkowania statycznego, std::threadstaje się bezużyteczny z powodu tych błędów / funkcji gcc:

• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590
• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740

Mianowicie, jeśli zadzwonisz std::thread::detachlub std::thread::joindoprowadzi to do wyjątku lub awarii, podczas gdy boost::threaddziała dobrze w tych przypadkach.

Sprawa Enterprise

Jeśli piszesz oprogramowanie dla przedsiębiorstwa, które musi działać na średniej lub dużej różnorodności systemów operacyjnych, a co za tym idzie, kompilować je z różnymi kompilatorami i wersjami kompilatorów (zwłaszcza stosunkowo starymi) w tych systemach operacyjnych, radzę trzymać się z daleka od C ++ 11 na razie w ogóle. Oznacza to, że nie możesz używać std::threadi polecam używanie boost::thread.

Podstawowy / Tech Startup Case

Jeśli piszesz dla jednego lub dwóch systemów operacyjnych, wiesz na pewno, że będziesz musiał budować tylko za pomocą nowoczesnego kompilatora, który w większości obsługuje C ++ 11 (np. VS2015, GCC 5.3, Xcode 7), a jeszcze nie jesteś zależne od biblioteki boost, std::threadmoże to być dobra opcja.

Moje doświadczenie

Osobiście jestem zwolennikiem zahartowanych, intensywnie używanych, wysoce kompatybilnych, wysoce spójnych bibliotek, takich jak boost kontra bardzo nowoczesna alternatywa. Jest to szczególnie ważne w przypadku skomplikowanych tematów programowania, takich jak wątki. Ponadto od dawna odniosłem wielki sukces z boost::thread(i ogólnie ulepszeniem) w szerokiej gamie środowisk, kompilatorów, modeli wątków itp. Kiedy wybieram, wybieram przyspieszenie.

std::mutexWydaje się, że program Visual Studio 2013 zachowuje się inaczej niż program boost::mutex, co spowodowało pewne problemy (zobacz to pytanie ).

W odniesieniu do std :: shared_mutex dodanego w C ++ 17

Pozostałe odpowiedzi zapewniają bardzo dobry przegląd ogólnych różnic. Jest jednak kilka problemów związanych z std::shared_mutextym wzmocnieniem.

1. Muteksy z możliwością aktualizacji. Tych nie ma std::thread. Umożliwiają one zmianę czytelnika na pisarza bez pozwolenia innym pisarzom na wejście przed tobą . Umożliwiają one wykonywanie takich czynności, jak wstępne przetwarzanie dużych obliczeń (na przykład ponowne indeksowanie struktury danych) w trybie odczytu, a następnie aktualizację do zapisu w celu zastosowania ponownego indeksowania, przytrzymując blokadę zapisu tylko przez krótki czas.

2. Uczciwość. Jeśli masz ciągłą aktywność w czytaniu z a std::shared_mutex, twoi pisarze będą na czas nieokreślony zablokowani. Dzieje się tak, ponieważ jeśli pojawi się inny czytelnik, zawsze będzie miał pierwszeństwo. W przypadku boost:shared_mutexwszystkich wątków ostatecznie nadany zostanie priorytet. ⁽¹⁾ Ani czytelnicy, ani pisarze nie będą głodni.

Tl; dr polega na tym, że jeśli masz system o bardzo dużej przepustowości, bez przestojów i bardzo dużej rywalizacji, std::shared_mutexnigdy nie zadziała bez ręcznego zbudowania systemu priorytetowego. boost::shared_mutexzadziała po wyjęciu z pudełka, chociaż w niektórych przypadkach może być konieczne majstrowanie przy nim. Twierdzę, że std::shared_mutexto zachowanie jest ukrytym błędem, który czeka na wystąpienie w większości kodu, który go używa.

⁽¹⁾ _{rzeczywiste algorytm wykorzystuje opiera się na scheduler wątku OS. Z mojego doświadczenia wynika, że ​​gdy odczyty są nasycone, w systemie Windows występują dłuższe przerwy (przy uzyskiwaniu blokady zapisu) niż w systemie OSX / Linux.}

Próbowałem użyć shared_ptr z std zamiast boost i faktycznie znalazłem błąd w implementacji gcc tej klasy. Moja aplikacja ulegała awarii z powodu dwukrotnego wywołania destruktora (ta klasa powinna być bezpieczna dla wątków i nie powinna generować takich problemów). Po przejściu do boost :: shared_ptr wszystkie problemy zniknęły. Obecne implementacje C ++ 11 wciąż nie są dojrzałe.

Boost ma też więcej funkcji. Na przykład nagłówek w wersji standardowej nie zapewnia serializatora do strumienia (tj. Cout << duration). Boost ma wiele bibliotek, które używają własnych, itp. Odpowiedników, ale nie współpracują z wersjami standardowymi.

Podsumowując - jeśli masz już aplikację napisaną przy użyciu boosta, bezpieczniej jest zachować kod w takiej postaci, w jakiej jest, zamiast wkładać trochę wysiłku w przejście na standard C ++ 11.