유저레벨 쓰레드에서의 메모리 배리어에 대해 질문을 드리고 싶습니다.

현재 문제 발생 원인이 유저단에서 지원하는 배리어 api만 있으면 해결가능 하다라는 결론을
내셨는데.. 정확히 어떤 문제? 인지 상세히 기술해 주시면 많은 분들이 공부도 되고, 좀더 조언을 드릴 수 있지 않을까요?

질문 내용으로만 봐서는 단정지을수 없지만
뮤텍스 정도로 해결 가능하지 않나요?
뮤텍스로 해결할 수 없으니 질문을 올리신거 같은데
왜 뮤텍스로 해결이 안되는지에 대한 이유도 같이 기술하면 좋을 것 같아요~ ㅎㅎ

가능하지 않은 방법을 사용하고 계신데...
(인터럽트핸들러에서 콜백으로 유저스페이스 쓰레드 자원(변수?)를 접근한다? 어떻게 알고!?)

아마 문제 해결 및 구현 방법은 보안이 아닐거라 생각 됩니다.

천천히 한번 말씀해 보세요

혹시 아나요?
리눅스에 불가능한 혹은 쉽게 할 수 있는 방법이 있는데 어렵게 구현하려고 끙끙하고 계시는거
쉽게 할 수 있는 방법 조언해 줄련지...

보통의 linux kernel 및 device driver 혹은 그 user program 은 다음과 같은 방식을 사용합니다.

1. HW device driver가 있음
HW 를 제어할 수 있는 함수 제공 및 인터럽트 핸들러를 등록함.
2. 1번에서 만들어진 함수를 호출하고, User space fs 대응 driver 가 있음.
HW를 제어함, User space에서 open,read,write,ioctl 에 대응함.
3. User program 이 있음. 2번을 open 해서 write,read,ioctl 함.

굳이 이렇게 하지 않아도 되지만 보통(99% 이상이)은 이렇습니다.
위에서 기술한 방식대로 안되어 있다면 위와 같이 하는걸 추천 드리며,
위에서 말한 방식과 동일 하다면

2.번의 드라이버에서는 오직 인터럽트 발생시 HW에서 값을 읽어서 내부에 저장을 해 놓고
User 에서 요청이 있을시 값 만 전달 해 주면 됩니다.

바꿔 말하면 HW device driver 와 User space 사이의 완충 알고리즘? 매커니즘이 필요합니다.
User space에서 read 를 호출 했다고 해서 HW에서 바로 read 하지 말고 완충버퍼에서 읽어가도록 하세요.