저렇게 SetEvent를 주석을 달고 했을때 무한 대기상태로 들어가는건 이해가 됬습니다. 저상태에선 브레이크 포인트를 잡는다던가, 디버그 행동을 할 수가 없나요?? 저는 현재 WaitForSingleobject가 쓰레드 함수가 끝날때까지 대기 하는것으로 이해하고 있습니다. 쓰레드 함수가 정상적으로 끝나는게 아닌, 외부 함수에 의해서 강제강료 했을때 무한대기 하는 상태가 발생하는데, SetEvent를 호출하지않고 강제종료되는 경우를 고려할수있을까요?
안녕하세요 ! 강의를 보다가 궁금한 부분이 생겨서 질문 드립니다 ! 상위 QueryProvider를 만들 때 ReactQueryStreamedHydration로 미리 감싸면 강의에서 소개 해준 dehydrate(queryClient)로 감싸는 작업을 하지 않아도 되나요? <QueryClientProvider client={client}> <ReactQueryStreamedHydration>{children}</ReactQueryStreamedHydration> </QueryClientProvider> dehydrate와 HydrateBoundary가 정확히 어떤 역활을 하는지 궁금합니다 const dehydratedState = dehydrate(queryClient); return ( <HydrationBoundary state={dehydratedState}> <MoreListView keyword={keyword} /> </HydrationBoundary> ); prefetchInfiniteQuery의 queryFn과 useInfiniteQuery의 queryFn은 똑같이 작성해야 하나요?? 만약 이렇게 하면 안된다면 전달하고자 하는 매개변수를 client component에서 전달하고자 할 때 어떻게 해야할 지 고민이 됩니다. (전달하는 상태 값은 useContext로 만든 상태 값입니다..) // prefetch 부분 const queryClient = new QueryClient(); await queryClient.prefetchInfiniteQuery({ queryFn: fetchMoreList, }); // client component 부분 useInfiniteQuery<Dummy[], Object, InfiniteData<Dummy[]>, [_1: string, _2: string], number>({ queryFn: ({ pageParam, queryKey }) => fetchMoreList({ pageParam, queryKey, sort }), });
[질문 내용] 복습 중 테스트 오류가 났는데 이유를 모르겠습니다.. entity repository application.yml test build.gradle test code하기 전에 main()을 run 했을 때는 제대로 실행되고 h2 웹 콘솔에서도 Member 테이블이 생긴 것을 확인했습니다. 그런데 테스트 코드를 실행하면 아래와 같은 에러가 뜹니다.. 도움 부탁드립니다! 에러
안녕하세요, 좋은 강의 감사합니다. 강의 자료대로 구현하여 잘 사용 중입니다. 아래 사진을 보시면 디버그 모드에서 live expression 탭의 변수값이 실시간으로 보여지지 않고 있어요. 혹시 볼 수 있는 방법이 있을지요? Release 모드에서 Debug 모드로 변경하여도 되지 않고 있습니다. 감사합니다.
과제로 내주신 것 중 std::thread 와 std::promise 를 사용하는 것을 먼저 해보고 divide and conquer 를 std::thread 를 이용해서 구현하는 것을 해봤는데, 궁금증이 생겨서 질문드렸습니다. 강의 영상 막바지에 보여주셨던 std::async 와 std::future 를 사용했던 예제를 참고해서, 하나의 변수에 여러 스레드가 값을 누적시키는 것이 아닌 각자의 local sum 에 값을 누적시킨 후 마지막에 모두 더하는 방식으로 구현해봤습니다. // TODO #1 : use divide and conquer strategy for std::thread cout << "thread" << endl; { const auto sta = chrono::steady_clock::now(); unsigned long long sum = 0; vector<std::thread> threads; vector<unsigned> sums; threads.resize(n_threads); sums.resize(n_threads); const unsigned n_per_thread = n_data / n_threads; for (unsigned t = 0; t < n_threads; t++) { threads[t] = std::thread(dotProductThread, std::ref(v0), std::ref(v1), t * n_per_thread, (t + 1) * n_per_thread, std::ref(sums[t])); } for (unsigned t = 0; t < n_threads; t++) { threads[t].join(); sum += sums[t]; } const chrono::duration<double> dur = chrono::steady_clock::now() - sta; cout << dur.count() << endl; cout << sum << endl; cout << endl; } 그리고 처음에는 std::thread 가 사용할 함수인 dotProductThread 의 구현을 call by reference를 반환값처럼 사용하도록 아래와 같이 구현했습니다. auto dotProductThread(const vector<int>& v0, const vector<int>& v1, const unsigned i_start, const unsigned i_end, unsigned& local_sum) { for (unsigned i = i_start; i < i_end; i++) { local_sum += v0[i] * v1[i]; } } 그런데 실행해봤더니 정답은 제대로 나오지만 속도가 제가 구현한 std::thread 와 std::promise 를 사용한 예제보다 훨씬 느렸고, 심지어 std::innerproduct 보다도 느렸습니다. 뭐가 문제일까 싶어 여러가지를 바꿔보다가 아래와 같이 dotProductThread 함수에서 매번 레퍼런스에 값을 더하지 않고 변수를 하나 선언해 누적하다가 마지막에만 넘겨주도록 하였습니다. auto dotProductThread(const vector<int>& v0, const vector<int>& v1, const unsigned i_start, const unsigned i_end, unsigned& local_sum) { unsigned t = 0; for (unsigned i = i_start; i < i_end; i++) { t += v0[i] * v1[i]; } local_sum = t; } 실행했더니 속도가 std::thread 와 std::promise 를 사용한 예제와 거의 비슷하게 나와주었습니다. call by reference로 전달된 참조에 너무 빈번하게 접근해도 퍼포먼스 저하가 일어난다고 봐도 될까요? 그리고 시험삼아 출력문을 dotProductThread 내에 작성해봤더니 race condition은 일어나지 않는 것 같았습니다. 이런 경우 굳이 std::atomic 이나 뮤텍스를 사용할 필요는 없나요? 또는 작업이 더욱 복잡해진다면 안정성을 위해 사용해줘야 하는 걸까요?(프로그래머가 미처 고려하지 못한 상황이라거나)
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세요. function solution(arr) { let answer = arr; for (let i = 0; i < arr.length; i++) { for (let j = 1; j < arr.length; j++) { if (arr[j - 1] > arr[j]) { [arr[j - 1], arr[j]] = [arr[j], arr[j - 1]]; } } } return answer; } // test case console.log(solution([11, 7, 5, 6, 10, 9]));
버프류 스킬 AttackBuff.ClearEffect() 메서드 관련 궁금한 점이 있습니다. public override bool ClearEffect(EEffectClearType clearType) { if(base.ClearEffect(clearType) == true) RemoveModifier(Owner.Atk, this); return true; } 여기서 base.ClearFffect() 는 ObjectManager.Despawn() 을 호출하고, 이건 또 ResourceManager.Destroy() 를 호출함으로써 AttackBuff가 붙어있는 EffectBase 프리팹을 날려버리면서 true 를 반환하는걸로 이해하는데요, 이 경우 AttackBuff 인스턴스가 날라가게 되는데 그 다음줄 RemoveModifier가 실행되고, 또 자기 자신을 인자로 넘겨줄 수가 있나요? RemoveModifier(Owner.Atk, this);
1.AppConfig와 MeberApp를 분리한 이유를 잘 모르겠습니다. MemberApp에서 MemberService의 구현체 확인이 안되고 확인하려면 다시 AppConfig를 열어야하는데, 분리한 이유가 있나요? (예제 코드이다 보니깐 AppConfig의 장점이 와닿지가 않네요.. 현재로선 득보다 실이 더 큰 느낌이 들어요) 2. MemberApp의 역할의 경계를 어디까지 잡는지 잘 모르겠습니다.
