초창기 리눅스는 포직스 쓰레드 api를 유저 레벨에서 구현했었습니다. 그러니까 포직스 쓰레드 api를 부르면 리눅스 쓰레드 씨스템 콜이 호출되는 형식으로요(clone()이나 fork(), 사실 둘은 같은 구현이라고 알고 있습니다.)
그런데 그렇게 하니 쓰레드 성능도 안나오고, 표준과 안 맞아 떨어지는 문제(잘은 모릅니다만 thread마다 다른 pid가 부여 되는 문제 등)도 있고 해서 포직스 쓰레드 api를 커널 레벨에서 구현하기 시작했었는데, 그 당시에 구현체가 2개가 있었습니다. 그게 NGPT와 NPTL이죠. 그러다 NPTL이 살아남아서, 리눅스 포직스 쓰레드 api 공식 구현은 NPTL이 되었습니다.
Quote:
NPTL이 GLIBC에 포함되어 있는 것이라고 하고
제가 아는 한에서는, 리눅스 시스템 콜은 모두 glibc에 들어가 있습니다. 그러니까 커널 구현이 들어가 있는게 아니라, 유저 레벨에서 호출할 수 있는 래퍼가 들어가 있는거죠. 그걸 호출하면 트랩이 발생하게 만드는 등등. 포직스 쓰레드 API도 당연히 glibc에 들어가 있을테죠.
Quote:
32bit platform에서는 쓰이지 않고, 64bit platform에서만 쓰인다.
제가 아는 한에서는, 이건 아닌 듯 합니다만.
한 때 LinuxThread랑 NPTL구현이 구체적으로 어디부터가 커널 수준이지 알아보려고 잠깐 뜯어보기도 했었는데, 너무 옛날이라 정확하게 기억이 나지 않아서 쓴 내용이 틀릴 수도 있습니다 ^^;;
$ /lib/libpthread.so.0
Native POSIX Threads Library by Ulrich Drepper et al
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Forced unwind support included.
NPTL이 GLIBC와..
어떤 관련이 있는지 좀 찾아보니,,
NPTL이 GLIBC에 포함되어 있는 것이라고 하고
32bit platform에서는 쓰이지 않고, 64bit platform에서만
쓰인다고 하던데,,맞는 이해인가요?
리눅스 포직스
리눅스 포직스 쓰레드 api 구현의 발전과 관계가 있습니다.
초창기 리눅스는 포직스 쓰레드 api를 유저 레벨에서 구현했었습니다. 그러니까 포직스 쓰레드 api를 부르면 리눅스 쓰레드 씨스템 콜이 호출되는 형식으로요(clone()이나 fork(), 사실 둘은 같은 구현이라고 알고 있습니다.)
그런데 그렇게 하니 쓰레드 성능도 안나오고, 표준과 안 맞아 떨어지는 문제(잘은 모릅니다만 thread마다 다른 pid가 부여 되는 문제 등)도 있고 해서 포직스 쓰레드 api를 커널 레벨에서 구현하기 시작했었는데, 그 당시에 구현체가 2개가 있었습니다. 그게 NGPT와 NPTL이죠. 그러다 NPTL이 살아남아서, 리눅스 포직스 쓰레드 api 공식 구현은 NPTL이 되었습니다.
제가 아는 한에서는, 리눅스 시스템 콜은 모두 glibc에 들어가 있습니다. 그러니까 커널 구현이 들어가 있는게 아니라, 유저 레벨에서 호출할 수 있는 래퍼가 들어가 있는거죠. 그걸 호출하면 트랩이 발생하게 만드는 등등. 포직스 쓰레드 API도 당연히 glibc에 들어가 있을테죠.
제가 아는 한에서는, 이건 아닌 듯 합니다만.
한 때 LinuxThread랑 NPTL구현이 구체적으로 어디부터가 커널 수준이지 알아보려고 잠깐 뜯어보기도 했었는데, 너무 옛날이라 정확하게 기억이 나지 않아서 쓴 내용이 틀릴 수도 있습니다 ^^;;
그냥 이렇게
그냥 이렇게 확인하세요.
----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러
----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러
댓글 달기