From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12133 invoked by alias); 15 Feb 2009 10:50:52 -0000 Received: (qmail 12124 invoked by uid 22791); 15 Feb 2009 10:50:52 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00 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; Sun, 15 Feb 2009 10:50:46 +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 948EE636DE for ; Sun, 15 Feb 2009 11:50:44 +0100 (CET) Message-ID: <4997F382.7080201@t-online.hu> Date: Sun, 15 Feb 2009 10:50:00 -0000 From: Szentirmai Gergely 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/msg00079.txt.bz2 I have read the documentation before, and the main problem is what you are mentioning too. You cannot call blocking instructions, such as |cyg_semaphore_wait, so if a thread used the shared resource when the scheduler started the DSR (we use semaphores) the DSR cannot wait. You would say we are not allowed to use blocking instructions in DSR context, but locking the DSR, masking the interrupt, or locking the scheduler has the same effect, the DSR code is blocked (not at the theoretical ||cyg_semaphore_wait, ||but at the "start") (or it is an event worth solution than allow ||cyg_semaphore_wait (rework the implementation of semphores)). Thank you! Gergely Szentirmai | Paul D. DeRocco írta: >> From: Reg >> >> 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? >> > > Ah, I see your fundamental problem. You've misread the documentation if you think all these functions aren't usable in DSR context. Most are, as long as you don't use a function that may block. Read the bit at the end of each function description in the Reference Manual for details about the valid contexts they can be used in. > > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss