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=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,586481a3e3e7fdab X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-28 07:53:05 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <7sbsn966zs.fsf@salmon.ls.fi.upm.es> Subject: Re: GNAT Task Scheduling in Linux Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Thu, 28 Jun 2001 10:53:00 EDT Organization: http://www.newsranger.com Date: Thu, 28 Jun 2001 14:53:00 GMT Xref: archiver1.google.com comp.lang.ada:9203 Date: 2001-06-28T14:53:00+00:00 List-Id: In article <7sbsn966zs.fsf@salmon.ls.fi.upm.es>, Manuel Carro says... > Hello. I have a question regarding the (default) task scheduling >policy of GNAT (3.13p) in Linux. I have a simple program which starts >some tasks which increment a nonprotected variable. The tasks should >start (almost) at once, so that the variable is incremented >concurrently (and wrongly), and the problem is that every task is >started only after another task has finished. Hence, the problem of >concurrent access does not show up. I belive the FSU threads were designed to allow validation of the Ada compiler. As such, they follow the priority scheduling clause of the real-time annex (LRM D.2) to the letter. In particular, it implements the FIFO_Within_Priorities task dispatching policy, and follows the rules set out in D.2.1 for switching at "task dispatching points". The language only defines such points to be "delay" statements, rendezvous, and the changing of the running task's priority, if I read it right. If they only implemented the minimum required to conform with the LRM, then you can't exepect to see task switches at any other time. You might try making one of the tasks higher priority, and having it put itself to sleep with "delay" statements before a variable update. That way its possible that the delay might expire, forcing the start of the higher-priority task, during an update to the variable in the lower-priority task. It'd be hit-or-miss causing an actual invalid update this way, but these are always hit-or-miss types of errors. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com