C 소켓 API는 스레드로부터 안전합니까?

리눅스와 Win32 소켓 API를 모두 사용하고 있습니다. 내 프로그램에서 여러 스레드가 소켓 핸들을 공유합니다. 특히, 복수의 스레드는 send을 공유 소켓 핸들 (즉, 동일한 포트)로 호출한다. 이 경우 스레드 안전을 위해 잠금을 설정해야합니까? 대답을 찾을 수 없었습니다. 시험을 보지만 경험을 듣고 싶습니다.C 소켓 API는 스레드로부터 안전합니까?

EDIT : 소켓을 통한 전송 데이터는 원자 적 조작이 아닙니다. 확실히 스레드 안전을 위해 뮤텍스를 사용해야합니다. 그러나, 시스템 API 자체 내부 잠금을 가질 수 있는지 궁금 해서요. 그렇다면 우리는 우리 자신의 자물쇠를 넣는 것을 생략 할 수 있습니다.

이 질문은 fprintf 기능에도 적용될 수 있습니다. 나는 그런 시스템 API가 그들 자신의 잠금을 가지고 있을지 궁금해하고있다. 내 경험에 의하면 파일이나 표준 출력 (예 : 일관되지 않거나 예측할 수없는 출력이지만 프로그램이 충돌하지 않음)에 경주가 있었지만 fprintf을 호출하면 내 프로그램이 죽지 않았습니다. 이는 fprintf에서 내부 프로그램을 보호하기위한 잠금 장치가 있음을 나타냅니다. 데이터 구조.

출처

2010-03-01 minjang

같은 소켓에 여러 개의 스레드를 읽고 쓰는 것은 제 생각에는 사실상의 디자인 문제입니다. – theMayer

소켓을 통해 데이터를 보내는 것은 원 자성 트랜잭션이 아닙니다. 모든 비 원 자성 트랜잭션은 잠금/동기화가 필요합니다. 이것은 플랫폼과 독립적입니다.

출처

2010-03-01 07:48:42 weismat

감사합니다. 예, 저는 이것이 원자 적 조작이 아니라는 것을 압니다. 그러나, 시스템 API 자체 내부 잠금을 가질 수 있는지 궁금 해서요. – minjang

하지만 그들은 그것들을 원자 단위로 만들 수 있다면 ... – EJP

소켓은 C++ 표준의 일부가 아니므로 구현에 따라 다릅니다. 일반적으로 send은 원자 적 연산이 아니므로 스레드로부터 안전하지 않습니다. 자세한 내용은 this discussion을 확인하십시오.

EDIT : OS는 내부 구조를 보호하기 위해 내부 잠금을 가지고 있거나 가질 수 없었습니다. 구현에 달려 있습니다. 그래서 당신은 그것에 의지해서는 안됩니다.

출처

2010-03-01 07:57:03

POSIX send/recv와 같은 소리는 링크와이 토론에 기초한 thread safe입니다 : http://stackoverflow.com/a/1981439/602245 – Brett

아니요, accept로 만든 변수는 뮤텍스 일 필요는 없습니다. 쓰레드가 사용하는 데이터는 적어도 세마포어 여야한다.

sem_t* sem_data;

출처

2012-08-23 01:20:44 November

여러 소켓 close() 파일 설명자 호출은 동시 환경에서 매우 위험합니다.

일반적으로 여러 호출이 무시되지만 다른 스레드가 다른 파일 설명자를 열 경우 상당히 자주 이전 파일 설명자를 가져오고 악몽이 시작됩니다.

출처

2013-09-10 13:58:24 MajstorKvaris

C 소켓 API는 스레드로부터 안전합니까?

답변

관련 문제