From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2036 invoked by alias); 1 Apr 2013 11:59:01 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 1979 invoked by uid 89); 1 Apr 2013 11:58:46 -0000 X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.1 Received: from www.meduna.org (HELO meduna.org) (92.240.244.38) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 01 Apr 2013 11:58:16 +0000 Received: from dial-95-105-165-4-orange.orange.sk ([95.105.165.4] helo=[192.168.130.22]) by meduna.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1UMdND-00036R-UK; Mon, 01 Apr 2013 13:58:10 +0200 Message-ID: <51597647.1010803@meduna.org> Date: Mon, 01 Apr 2013 11:59:00 -0000 From: Stanislav Meduna User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: randyqiuxy CC: eCos Discussion References: , <51546EFC.5050603@dallaway.org.uk> , <5158269C.5000804@meduna.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authenticated-User: stano@meduna.org X-Authenticator: dovecot_plain X-Spam-Score: -6.9 X-Spam-Score-Int: -68 X-Exim-Version: 4.72 (build at 25-Oct-2012 18:35:58) X-Date: 2013-04-01 13:58:10 X-Connected-IP: 95.105.165.4:15074 X-Message-Linecount: 85 X-Body-Linecount: 70 X-Message-Size: 3649 X-Body-Size: 2812 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Subject: Re: [ECOS] why should ISR arrange that the same interrupt would not recur until DSR completed? X-SW-Source: 2013-04/txt/msg00000.txt.bz2 On 31.03.2013 16:50, Randy wrote: >> Remember, neither the ISR nor DSR can block. > I know this rule, but I'd like to ask you why. Well I cannot comment on design choices made by the eCos developers, but generally: - an ISR cannot block by definition. It is not a thread, it has no state (runnable / blocked / ...), it cannot be scheduled by the scheduler, it often gets special handling by the hardware itself, ... Its "scheduler" is the hardware, not the OS. - a DSR is basically "the rest of the interrupt handler that can run later with interrupts enabled". It is not a thread either, it cannot be preempted, it has no priority, all pending DSRs are queued and serviced in a FIFO manner. You can find some discussion in a 10 year old thread at http://www.sourceware.org/ml/ecos-discuss/2003-01/msg00330.html > I think that one DSR interrupted by other interrupt could continue to > finish the remainder parts when it reschedule to current thread, > then, why wait-semaphore in DSR which cause to switch to another > thread is prevented by scheduler? This maybe because scheduler is > locked and it could not work, but why don't we enable this function > in DSR? Becasue the DSR is not a thread. If you need it to be, you can make the DSR minimal (just post an event to a normal thread) and do your processing there. If the processing takes a considerable amount of time, you should do that anyway. DSR is just a bridge between the interrupt handler world and a thread world. >> Disabling interrupts outside of interrupt handlers is generally frowned upon. > I don't see this, could you please make it more clearly? Generally in a real-time operating system achieving the best possible interrupt latency and doing things deterministically are the main goals, more important than the best possible general performance. Disabling interrupts adds to the possible worst-case latency. Having an unbounded number of anything in some queue or waiting until a thread (possibly low-prio) is done with some lock breaks determinism. >> 2) The list of pending DSRs is now upper bounded. With the same >> interrupt enabled it would become unbounded. > I'd like to know which case could cause a pending DSR? There is a DSR queue. If your DSR could be preempted by the same interrupt again, that ISR would possibly queue another DSR for the same interrupt. And again and again. Now the maximum number of DSRs in the queue basically equals the number of possible interrupts. > Does one DSR interrupted by other interrupt could become a pending DSR? > No, right? It queues the own DSR which gets processed after all already queued DSRs. Then the originally interrupted DSR continues. A real-time operation is not an easy task. Regards -- Stano -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss