Dear Mr. [EMAIL PROTECTED] ! ���������� �������. ��������� ����� ������ threads ��� �������. �������������� :) ��������� �� ��� ��� �� ����� � �������� �������� � RedHat �������� ������ �� �����. ��� ��� ��������, ��� ������ Native Threads �� Rawhide, ��� ��� ����� ���������, ��� ������� glibc-�. � ����� ���� - ����� ������� �� LOR.
��� �������� �� ������: The result is this thread library which is, unlike previous attempts, a very thin layer on top of the kernel. This helps to achieve a maximum of performance for a minimal price. ---- A white paper (still in its draft stage, though) describing the design is available at http://people.redhat.com/drepper/nptl-design.pdf ----- the new library is based on an 1-on-1 model. Earlier design documents stated that an M-on-N implementation was necessary to support a scalable thread library. This was especially true for the IA-32 and x86-64 platforms since the ABI with respect to threads forces the use of segment registers and the only way to use those registers was with the Local Descriptor Table (LDT) data structure of the processor. ---- + less complex implementation; + avoidance of two-level scheduling, enabling the kernel to make all scheduling decisions; + direct interaction between kernel and user-level code (e.g., when delivering signals); + and more and more. ---- (!!!!!!!!!!!!!!!!!!!!!!!!) Initial confirmations were test runs with huge numbers of threads. Even on IA-32 with its limited address space and memory handling running 100,000 concurrent threads was no problem at all, creating and destroying the threads did not take more than two seconds. This all was made possible by the kernel work performed as part of this project. ������ ����������� �� �����? ������� �������� - �������� ���������� �� 1�� ������ �������� �� 4000-�� �����. ---- The only limiting factors on the number of threads today are resource availability (RAM and processor resources) and architecture limitations. Since every thread needs at least a stack and data structures describing the thread the number is capped. On 64-bit machines the architecture does not add any limitations anymore (at least for the moment) and with enough resources the number of threads can be grown arbitrarily. This does not mean that using hundreds of thousands of threads is a desirable design for the majority of applications. At least not unless the number of processors matches the number of threads. But it is important to note that the design on the library does not have a fixed limit. The kernel work to optimize for a high thread count is still ongoing. Some places in which the kernel iterates over process and threads remain and other places need to be cleaned up. But it has already been shown that given sufficient resources and a reasonable architecture an order of magnitude more threads can be created than in our tests on IA-32. --- On an old IA-32 dual 450MHz PII Xeon system 100,000 threads can be created and destroyed in 2.3 secs (with up to 50 threads running at any one time). �������? ������� �������� ������������? ---- ��� ��� ����� ��������� - The thread library is designed to be binary compatible with the old LinuxThreads implementation. ------ ������ ������ ��� ��� ��������� ���� � ������ ���������� ������, �� ����� 2.5, ���� ����� ����� ���������, � ���� ������� �������� ������� ��� ���� �����. Thank you! ----------------------------------------------------------------------------------------- Fedorishenko Denis Olegovich [EMAIL PROTECTED] * Tel: +380 679322793 www.nuclearcat.com * www.planetsky.org * www.itelsat.org ===================================================================== If you would like to unsubscribe from this list send message to [EMAIL PROTECTED] with "unsubscribe oops" in message body. Archive is accessible on http://lists.paco.net/oops-rus/
