From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24232 invoked by alias); 30 May 2006 11:47:19 -0000 Received: (qmail 24224 invoked by uid 22791); 30 May 2006 11:47:18 -0000 X-Spam-Check-By: sourceware.org Received: from nz-out-0102.google.com (HELO nz-out-0102.google.com) (64.233.162.194) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 30 May 2006 11:47:16 +0000 Received: by nz-out-0102.google.com with SMTP id n29so737173nzf for ; Tue, 30 May 2006 04:47:14 -0700 (PDT) Received: by 10.65.22.6 with SMTP id z6mr1656149qbi; Tue, 30 May 2006 04:47:14 -0700 (PDT) Received: by 10.64.199.17 with HTTP; Tue, 30 May 2006 04:47:14 -0700 (PDT) Message-ID: <69dd805e0605300447h224b150ale6b39bb9e691ed80@mail.gmail.com> Date: Tue, 30 May 2006 11:47:00 -0000 From: "Fabian Scheler" To: "Luis Friedrich" Cc: "=?ISO-8859-1?Q?Wolfgang_K=F6bler?=" , "R Vamshi Krishna" , ecos-discuss@ecos.sourceware.org In-Reply-To: <447C2A98.4050309@inf.ufsc.br> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <447C2A98.4050309@inf.ufsc.br> X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Hard-Realtime behaviour X-SW-Source: 2006-05/txt/msg00248.txt.bz2 > Most important of all in hard real-time systems is predictability which > means you are able to > calculate the execution time (WCET) of your system and so you can > predict it. I think, it is sufficient to be deterministic - you cannot predict the flow of control in an event-driven system, it depends on the occurence of events, so event-driven systems are not really predictable in comparison to time-driven systems, but, nevertheless, you can build hard real-time systems with an event-triggered approach, too. > Also important is to be able to describe your application to the system, > like period, deadline, priority and all the parameters that describe the > temporal behavior of tasks (or threads). agree > Finally, the scheduler or the scheduler mechanisms that are available > are also important to have flexibility enought to use different > scheduling policies. Why? There are many time-driven operating systems that just support schedule tables and these operating systems are definitely able to deal with hard deadlines. > How you define for example the temporal paremeters of a thread on eCos? > - the function /cyg_thread_create/ has no arguments about the > temporal behavior of the thread Why is an explicit notion of these parameters necessary during runtime? One should make up his mind about this stuff before the system is online, therefore, also the problems related to these timing parameters should be resolved offline, so, there should be no need to have this information during runtime except, maybe, debugging. Ciao, Fabian. -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss