From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29297 invoked by alias); 14 Feb 2009 22:32:24 -0000 Received: (qmail 29287 invoked by uid 22791); 14 Feb 2009 22:32:23 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_40 X-Spam-Check-By: sourceware.org Received: from Dividenda.externet.hu (HELO dividenda.externet.hu) (212.40.96.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 14 Feb 2009 22:32:14 +0000 Received: from [192.168.1.3] (fibhost-176-206.fibernet.bacs-net.hu [85.66.176.206]) by dividenda.externet.hu (Postfix) with ESMTP id EFE75636DE for ; Sat, 14 Feb 2009 23:32:13 +0100 (CET) Message-ID: <4997466A.2040403@t-online.hu> Date: Sat, 14 Feb 2009 22:32:00 -0000 From: Reg User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: eCos Discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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 Subject: Re: [ECOS] Interrupt vs Thread - shared resource X-SW-Source: 2009-02/txt/msg00076.txt.bz2 Thank your for your answer! I understand, and agree with all the stuff that you wrote (the need of ISR, DSR, and the solution). The only reason why I'm calling these solutions "hack" (in the meaning, that not the best soulution (workaround) ), because the code is depending on the calling "enviroment", so the code is somehow application specific. If for ex. semaphores could be used in DSRs, the code would be better, because the implementation of the semaphore would handle this group of questions (if you are in a thread, if you are in a DSR etc) So in other words, when you write a procedure, you have to think about "what will call this procedure/ or use the shared resource". If only threads use a resource, you use mutex. If a thread and a DSR is using it, you have to lock scheduler or mask the interrupt or lock the specific DSR, just because no sinchronization object can be used in DSRs. I think allowing the use of sinchronization objects in DSRs would be a great feature from eCos (would need to modify the implemetation of semaphore, mutex etc.) + better code quality + faster developement + less bugs... - a bit more time/resource So if DSRs are an interface or an intermediate layer between the "interrupt world" and the "thread world", why are we not allowed to use sinc. objects? Thank you! Gergely Szentirmai Paul D. DeRocco írta: >> From: Szentirmai Gergely >> >> Guys, thank you for your answers! >> >> Scheduler lock is an alternative to mask the interrupt, but masking the >> specific interrupt (or lock the specific DSR) is maybe better in >> performance, but too application specific (code reuse). >> As I read the scheduler manual: >> "However there is one situation where locking the scheduler is >> appropriate: if some data structure needs to be shared between an >> application thread and a DSR associated with some interrupt source, the >> thread can use the scheduler lock to prevent concurrent invocations of >> the DSR and then safely manipulate the structure." >> It writes the same thing. >> >> So there are two possible solution only; lock the scheduler, or mask the >> interrupt. >> Programatically I think both solution are not "pretty" enough, because I >> have to write procedures, that bother with these "hacks" (they are not >> high level enough), rather than use a mutex, but this is an eCos >> conceptional problem (what a shame, not too user-friendly), I think... >> >> Thank you for this dsr_lock idea too! >> > > I wouldn't call locking the scheduler a hack--it's the normal way to interface between threads and DSRs. If you use semaphores, etc., they do the locking and unlocking for you. Indeed, the whole reason for having DSRs is that it gives you an intermediate layer which can be disabled (by locking the scheduler) without disabling interrupts. > > If you have hardware that needs really fast response time, then you write an ISR which handles the really fast stuff, in which case the DSR has to do hardware-dependent interrupt masking when it accesses resources (buffer pointers, etc.) shared with the ISR. > > If your hardware isn't so insanely fast, then your ISR just invokes the DSR, the DSR talks to the hardware, and the thread "masks" DSRs by locking the scheduler when it accesses resources shared with the DSR. > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss