From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,a5681531ca1cf09e X-Google-Attributes: gid103376,public From: Geert Bosch Subject: Re: Tasking performance between Ada83 and Ada95 Date: 1997/06/22 Message-ID: <5oir0v$mgu$1@gonzo.sun3.iaf.nl>#1/1 X-Deja-AN: 251819880 References: <1997Jun6.115223.7384@relay.nswc.navy.mil> <7h6UFCAdNsmzEwg3@walsh.demon.co.uk> Organization: La Calandre Infortunee Newsgroups: comp.lang.ada Date: 1997-06-22T00:00:00+00:00 List-Id: Robert Dewar wrote: However, these days, more and more work is done on multi-processors, and then of course you have no choice if you want to distribute tasks across processors other than to use the system level threads. Furthermore, the efficiency hit from operating these threads on separate processors may indeed be significant. IMO the best solution would be to start X system level threads and implement a user-level threads package on top of it. Of course there will be a little extra need for locking, but on platforms suitable for multi-processing there exist CPU-instructions that make the implementation of fast locks possible. The interesting thing of course is that you can vary the number of system threads to customize the task model to the application. When N is the number of processors interesting values of X are: * 1 to limit the program to use 1 processor and no system context-switching * N, to achieve full multi-processing on a multi-processor * M, where M > N to simulate a multi-processor with M processors on a system with N processors (N = 1 for a uni-processor). This scheme could combine the advantages of user-level threads (fast context switches, fast priority changes and correct Ada semantics) with those of system-level threads (non-blocking system-calls and multi-processing). Regards, Geert