From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17784 invoked by alias); 12 Feb 2009 15:32:03 -0000 Received: (qmail 17692 invoked by uid 22791); 12 Feb 2009 15:32:03 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-fx0-f20.google.com (HELO mail-fx0-f20.google.com) (209.85.220.20) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Feb 2009 15:31:56 +0000 Received: by fxm13 with SMTP id 13so2371345fxm.6 for ; Thu, 12 Feb 2009 07:31:53 -0800 (PST) Received: by 10.181.33.8 with SMTP id l8mr339513bkj.155.1234452713152; Thu, 12 Feb 2009 07:31:53 -0800 (PST) Received: from localhost (212-41-76-225.adsl.solnet.ch [212.41.76.225]) by mx.google.com with ESMTPS id 18sm54949bwz.58.2009.02.12.07.31.50 (version=SSLv3 cipher=RC4-MD5); Thu, 12 Feb 2009 07:31:51 -0800 (PST) Date: Thu, 12 Feb 2009 15:32:00 -0000 To: "Szentirmai Gergely" , "eCos Discuss" Reply-To: Bob.Brusa@gmail.com From: Robert Brusa Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <4993822B.7010405@axelero.hu> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <4993822B.7010405@axelero.hu> User-Agent: Opera Mail/9.63 (Linux) 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/msg00062.txt.bz2 On Thu, 12 Feb 2009 02:58:03 +0100, Szentirmai Gergely wrote: > Hello > > I describe my problem with a simplified example: I have a thread, which > works with a buffer, and an ISR (or DSR), which would add some byte to > this buffer too, so it is a shared resource. Since it is unable wait for > a flag, or mutex in ISR, when the thread's code working with the buffer, > the interrupt can jam the data. > The only solution is to disable the interrupt for that critical section > in the thread? Isn't there a better solution? > > I hope I was clear. > > Thanks! > Gergely Szentirmai > > Well, you might block just this particular interrupt while messing around in the DSR using cyg_drv_interrupt_mask(vector) and enable it after the critical section using the correspoding unmask-routine. This would still allow other interrupts to come through. When a "normal" task accesses critical data that are also accessed by a DSR use cyg_drv_dsr_lock() etc..... Happy with this? Regards Robert -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss