Następujący kod ulega awarii w losowych odstępach czasu po utworzeniu z MSVC pod trybem Debug
, w przeciwieństwie do trybu Release
.Awaria podczas przypisywania do std :: future w trybie debugowania MSVC
#include <future>
using namespace std;
int main() {
auto l = [](){};
auto f = async(launch::async, l);
for (int i = 0; i < 1000000; ++i)
f = async(launch::async, l);
}
na konsoli mówi:
f: \ dd \ vctools \ crt \ crtw32 \ stdcpp \ Thr \ mutex.c (51) Muteks zniszczeniu podczas zajęty
Pełny stos wywoławczy to: https://pastebin.com/0g2ZF5C1
Oczywiście jest to po prostu próba stresu, ale czy robię coś zupełnie głupiego? Wydaje mi się, że to dobrze, aby przypisać nowe zadanie do istniejącej przyszłości, jak to powiedział, że operator=
:
prasowe jakikolwiek wspólny stan i przenieść-przypisuje zawartość innych do * to
(Z powodu http://en.cppreference.com/w/cpp/thread/future/operator%3D).
Czy to błąd w środowisku wykonawczym MSVC?
Co ciekawe, program zatrzymuje upaść, jeśli ręcznie zadzwonić wait() przed przypisaniem, tworząc w ten sposób pętlę w:
for (int i = 0; i < 1000000; ++i) {
f.wait();
f = async(launch::async, l);
}
Czy nie operator=
sam powinien zadzwonić wait
?
Tło:
_MSC_VER
równa 1911
Kod został zbudowany z pomocą:
Microsoft Visual Studio Community 2017 Preview(2)
Version 15.4.0 Preview 2.0
właśnie otworzył nowy C++ projektu.
Przydałaby się dokładna wersja pliku msvc i kompilatora. – Yakk
Po prostu zgadnij: Czasami prawdopodobnie "l" jest nadal wykonywane podczas próby ponownego przypisania f.Prawdopodobnie obciążenie związane z tworzeniem lambda podczas debugowania jest znacznie większe w porównaniu z obciążeniem pozostałej wersji kodu debugowania. To może wyjaśnić, że dzieje się tak tylko w wersji do debugowania. –
@Yakk Pewnie, zredagowałem to pytanie. –