사람들이 스레드를 사용하지 못하게하는 어떤 잘못된 아이디어가 있습니까? [닫은]

12

프로그램에서 스레딩을 구현하는 것은 어려운 일입니다. 그러나 분명한 필요성이 있어도 일부 사람들이이를 구현하지 않는 이유는 무엇입니까?

예 : 프로그램은 데이터베이스에서 데이터 세트를로드해야합니다. 작업자는 작업자 스레드에서 데이터베이스에서 데이터를 가져 와서 연결 한 다음 GUI에로드하여 GUI 스레드를 사용자에게 응답하게하는 것입니다. .

그러나 아니오, 나는 실이 사악하고 나쁜 것이라고 생각하는 사람들과 이야기를 나 and습니다. 심지어 일부 클래스 강사가 스레드 사용을 권유하지 않았으므로 사용을 다루기를 원하지 않는다고 들었습니다. 뭐???

하드웨어가 멀티 코어로 들어가면서 스레드를 더 잘 이해하고 사용하는 것을 두려워하지 않아야한다고 생각합니다. 나는 그것을 개인적으로 매혹적인 주제로 생각합니다.

스레딩에 대해 들어 본 내용이 잘못된 것은 무엇입니까?

multithreading

— 토니 라이온
소스

부적합과 부족은 스레드를 처리 할 수 없습니다. 진짜 질문은 : 당신은 그것에 대해 무엇을 할 것입니까?

— 직업

3

그것들은 잘못된 생각은 아니지만 스레드는 항상 피해야합니다. 스레딩 지원이 이미 올바르게 처리되어 모든 프로그래머가 직접 할 필요가 없도록 아키텍처를 올바르게 수행하십시오. 프로그래머가 모든 상황에서 스레드를 추가하는 것을 배우면 큰 문제가 발생합니다.

— tp1

질문을 다시 돌려 드리겠습니다. 병렬 처리 기능을 이용하는 다른 방법이 있는지 스스로에게 물었습니까? 또는 백서에서 말했거나 프로그래머가 멋지다고 생각한 것 때문에 스레딩으로 바로 넘어 갔습니까? 개인적으로, 나는 스레드보다 메시지를 서로 더 잘 전달하는 간단한 프로세스라는 아이디어를 좋아합니다. 나는 게으른 / 멍청한 / 서둘러? 예, 그리고 우리 모두는 다양한 범위로 있습니다.

— user1172763

19

스레딩은 어렵다

확실한. 그것은 될 수 있습니다. 그러나 사람들은 같은 것을, 그래서 열심히 그들의 머리에이 아이디어를 얻을 그들이 노력하고 귀찮게하지 않습니다 그것을 알아 내려고합니다.

불가능한 것 같지 않습니다.

— 스티븐 에버
소스

2

이 답변을 지원합니다. 사람들 은 어렵다고 생각 합니다. 그러나 당신이 이해하려고 충분한 시간을 보낼 때가 아닙니다.

11

@Pierre, 나는 많은 사람들의 hard에 대한 정의 가 "이해하기 위해 충분한 시간을 소비해야한다"고 기대합니다.

— Benjol

1

TPL 및 await/ async키워드를 사용하면 스레딩이 훨씬 쉬워집니다 :)

— Rachel

@Pierre 303 : 이해하기에 충분한 시간을 보낼 때 여전히 어려운 일이며, 실제로 가장 잘 이해하는 사람들은 최대한 피할 수 있습니다.

— Michael Borgwardt

9

어려운 스레딩 부분은 아니지만 동기화의 필요성과 스레드를 사용하여 제공되는 모든 것입니다. GUI 예제에서 주 스레드에 데이터 세트에 액세스 할 준비가되었음을 어떻게 알 수 있습니까? 콜백 전체를 전달합니까? 코드 전체에 여러 검사 변수를 분산합니까? Silverlight와 같은 일부 GUI 모델에는 스레드 선호도라는 것이 있는데, 이는 다른 스레드에서 메인 스레드에있는 GUI 요소에 액세스 할 수 없으므로 특정 정보가 더 처리 할 준비가되었습니다.

스레드에 대한 잘못된 말을 듣지 못했습니다. 방금 사용하는 알고리즘이 본질적으로 병렬이 아닌 경우 동기화가 나쁜 것에 관한 상황에 대한 사례 연구를 읽었습니다.

— davidk01
소스

자기주의 사항 : 병렬 알고리즘을 작성하십시오 ... 감사합니다.

— Droogans

메시지 대기열 (MFC에서와 동일) 그러나, 프로그래머가 메시지 큐를 방해하지 않도록 (메모리에서 데이터를 직접 공유함으로써), 이는 공격 가능한 공격 일지라도 실패한 것으로 보입니다.

— rwong

3

스레딩은 모든 문제를 해결합니다

성능 문제가있는 경우 스레딩으로 바로 넘어가 서는 안됩니다 .

스레드는 가벼움

스레드는 수십에서 20 인치로 가볍습니다. 수천 개의 스레드를 생성하는 것은 아닙니다.

스레딩은 쉽다 [Java]

스레드를 생성하기가 쉽다고해서 이점을 얻을 수있는 것은 아닙니다.

— 조쉬 케이
소스

기록상, Mac OS는 (기본 설치시) 512 개 이상의 스레드를 만들 수 없습니다.

— zneak

1

그것은 실제로 당신의 언어에 달려 있습니다. Erlang에서 백만 개의 스레드가 생성되는 것은 현대 서버는 물론 구형 노트북에서도 거의 눈에 띄지 않습니다. 실제로, 이들은 단지 스레드 일뿐만 아니라 본격적인 프로세스입니다 . 즉, 스레드보다 훨씬 무겁 습니다. 자체 프로그램 카운터 및 호출 스택 (스레드가 가지고있는 유일한 것임) 외에도 자체 힙과 자체 가비지 수집기가 있습니다.

— Jörg W Mittag

4

@ Jörg W Mittag : 나는 당신의 의견에 혼란스러워합니다. erlang은 OS가 스레드 또는 프로세스를 작성하는 방법을 어떻게 변경합니까?

— Steven Evers

1

@SnOrfus : Erlang은 OS 스레드를 사용하지 않습니다. BEAM, HiPE 및 Erjang의 세 가지 주요 Erlang 구현이 있습니다. BEAM 및 HiPE는 기본 구현이며 (OS 없이도 실행될 수 있음) 자체 프로세스를 구현합니다. Erjang은 JVM에서 실행되며 환상적인 Kilim 라이브러리를 사용하여 프로세스를 구현합니다.

— Jörg W Mittag

@ Jörg W Mittag : 내 질문 programmers.stackexchange.com/questions/28453/…을 고려할 때 , 나는 이것이 매우 흥미 롭습니다. 감사합니다.

— Steven Evers

1

스레드 안전하지 않은 (알지 못했던) 일부 라이브러리 / 함수를 사용하여 발생할 수있는 미친 버그를 수정하면 과도한 동기화가 필요하기 때문에 스레딩의 이점을 잃게됩니다.

스레드를 사용하면 사용하지 않을 때 수정할 수없는 버그가 발생할 가능성이 훨씬 높습니다.

— 카밀 쇼트
소스

고칠 수없는 버그? 나는 그 중 하나를 본 적이 없다 ..

— adamk

당신은 정말 당신이 고칠 수없는 버그를 본 적이 있습니까? 시간과 지불에 사용할 수 있었습니까?

— Kamil Szot

고칠 수없는 버그가 발생한 적이 없다면 업계에 오랫동안 종사하지 않은 것입니다. 12 년 이상 일하면서 내가 본 모든 프로젝트에는 아무도 고치지 않은 버그가 하나 이상 있으며 아무도 수정하거나 재현하는 방법을 모릅니다. 여기에는 작업에 사용 된 코드와 읽을 수있는 코드 (오픈 소스 코드)가 포함됩니다. 버그가없는 유일한 소프트웨어는 길이가 2 ~ 3 페이지 미만인 소프트웨어입니다. 그러나 모든 코드를 1-2 페이지 길게 만드는 것은 통합 버그가 있기 때문에 아무것도 해결하지 못합니다.

— slebetman

1

스레드가 사용하기 어려운 이유를 현명하게 요약하려면 :-
진실한 것들 1) 잠글 항목과 잠글 시점에 대한 동기화 및 신중한 디자인 결정 필요
2) 런타임 흐름에 대한 제어 없음
3) 어려운 디버깅
4) (매우 적음 시대) 플랫폼 호환성 :-라이브러리는 이것을 처리하기 위해 존재합니다

틀린 것 :
-1) 스레드 안전 및 재진입 기능의 혼란스러운 개념
2) 스레드는 종이에서는 좋아 보이지만 구현하기가 매우 어렵습니다

— 마노이 R
소스

이것들은 사실인가 사실이 아닌가? OP는 어떤 것이 사실이 아닌지 물었고 , 사람들이 멀티 스레드 프로그래밍을하는 것을 두려워했습니다.

— Steven Evers

실제로 잠금이나 동기화가 필요하지 않습니다. 메시지 전달 모델 (예 : erlang, scala) 및 STM 모델 (예 : clojure)도 있습니다. 그리고 잠금이 필요없는 스레드 안전 데이터 구조 (자바의 ConcurrentHashMap)와 잠금이 필요없는 원자 기본 요소가 있습니다.

— 케빈

1

코드에 대한 테스트를 작성하지 않으려면 스레드를 사용하지 마십시오.

스레드는 OS 및 컴퓨터 아키텍처의 기본 원리를 이해하지 못하는 일반적인 '복사 및 붙여 넣기'프로그래머를위한 것이 아닙니다. 프로그래머의 90 %가 Java에만 익숙하기 때문에 스레드를 사용해야하는 사람은 아닙니다. Java는 스레드를 "쉽게"만들지 만 동기화 된 구조를 사용하면 코드가 스레드에서 작동한다고 생각하는 많은 프로그래머를 보았습니다.

즉, 모두가 어딘가에서 시작해야하므로 회사의 생산 백엔드 서버를 업그레이드하는 첫 번째 스레딩 프로젝트를 만들지 마십시오.

— cmcginty
소스

스레드를 올바르게 수행하는 방법에 대한 리소스를 추천 할 수 있습니까?

— Jonathan

나는 이것이 해결되었다고 확신한다. 여기에서 시작해보십시오 stackoverflow.com/questions/660621/threading-best-practices

— cmcginty

이것의 문제점은 100 %의 테스트 적용 범위를 가지고 있어도 테스트가 공유 리소스와의 인터리브 방법과 관련된 모든 가능한 문제를 테스트가 해결할 수 있는지 알 방법이 없다는 것입니다. 반면에 무 공유 아키텍처를 사용하면 훨씬 쉬워집니다.

— Zachary K

1

예 : 프로그램은 데이터베이스에서 데이터 세트를로드해야합니다. 작업자는 작업자 스레드에서 데이터베이스에서 데이터를 가져 와서 연결 한 다음 GUI에로드하여 GUI 스레드를 사용자에게 응답하게하는 것입니다. .

이 상황이 4 가지 이상의 이유로 스레딩을 사용해야한다는 것을 알 수 없습니다.

데이터 검색은 매우 빠릅니다.
많은 업무용 응용 프로그램에서 사용자는 결과를 기다리는 1 초 또는 2 초 안에 응용 프로그램과 아무 관련이 없습니다. 또한 사용자는 원하는 작업을 완료하기 위해 데이터가 다시 나올 때까지 기다려야합니다. 반면에 쿼리는 한 번에 한 페이지의 정보 만 검색하도록 지능적으로 코딩 될 수 있으며 다른 최적화 기술이 응답 시간을 도울 수 있습니다.
웹 기반 인터페이스에서 스레딩 모델과 관련하여 링크가 활성화 될 수 있습니다.
스레딩은 인정함에 따라 복잡성을 추가합니다. 일부 개발자는 기능을 추가하거나 복잡한 코드를 디버깅하지 못할 수도 있습니다.

내 의견은 : 소프트웨어 유지 관리 및 안정성이 코드 우아함보다 조직에 더 중요하기 때문에 필요할 때 스레딩을 사용하십시오.

— 기회 없음
소스

1

첫 번째 요점은 분산 컴퓨팅의 오류 ( en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing )를 상기시킵니다 . 응답이없는 인터페이스를 위해 포인트 2에서 1 초 또는 2 초 이상 기다려야 할 때 끔찍한 클릭이 발생하기 시작하여 상황이 악화 될 수 있습니다.

— 확보

@Secure, 링크가 흥미 롭습니다. 공유해 주셔서 감사합니다. 이 시대에 인터페이스 나 전체 작업에 항상 사용자의 초점을 맞출 수 있을지 확신이 없습니다. E-Business 사이트에서는 사용자가 전혀 떠나지 않기를 동의합니다.

— NoChance

나는 초점에 대해 이야기하고 있지 않습니다. 사용자가 버튼을 클릭하면 데이터베이스가 쿼리되어 무언가가 수행되었다는 시각적 인 응답없이 인터페이스가 정지되는 경우 일부 사용자는 버튼을 다시 클릭하려고합니다. 다시 한번. 그런 다음 다른 버튼이나 옵션을 클릭하십시오. 나는 더 잘 알아야 할 관리자가 이것을하는 것을 보았습니다.

— 보안

결과 화면이 처음으로 그려 지지만 비어있는 경우에는 더 나빠집니다. 대부분의 최신 버전을 모르지만 이전 Outlook의 검색 결과는 좋은 예입니다. 검색을 시작할 때 검색 결과가 큰 경우 몇 초 동안 "결과 집합이 비어 있음"또는 이와 유사한 내용이 표시되고 발견되면 첫 번째 결과가 표시됩니다. 너무 초조하거나 급한 경우에는 이미 다음 폴더로 전환하여 아무 것도 없다고 생각합니다.

— 보안

1

@Secure, 당신의 요점을 참조하십시오. 여기서 설명하는 내용이 일관성이없는 사용자 인터페이스의 좋은 예를 보여줍니다. 설명한 내용은 파일을 검색 할 때도 발생합니다. 그러나 검색이 이미 시작되었다는 것을 사용자에게 알리는 것 이외의 다른 대답은 무엇입니까?

— NoChance