From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26084 invoked by alias); 11 Sep 2009 20:37:03 -0000 Received: (qmail 26076 invoked by uid 22791); 11 Sep 2009 20:37:02 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 11 Sep 2009 20:36:54 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id F35932F78034; Fri, 11 Sep 2009 21:36:51 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKvIEbZtq4cd; Fri, 11 Sep 2009 21:36:50 +0100 (BST) Date: Fri, 11 Sep 2009 20:37:00 -0000 Message-Id: From: Bart Veer To: Jim Bradleigh CC: ecos-discuss@ecos.sourceware.org In-reply-to: <110701.39566.qm@web87005.mail.ird.yahoo.com> (message from Jim Bradleigh on Mon, 7 Sep 2009 16:02:25 +0000 (GMT)) References: <3100D422DF3A4D7B9D337FD86D646F40@masahiro> <4A65D8D3.9060400@dallaway.org.uk> <3F8ED0BDC83C43259ADD0DDE963395DF@masahiro> <4A671AEE.2000101@dallaway.org.uk> <407D126036C3460AB7AA0264475F04E0@masahiro> <4A6971F2.1030100@dallaway.org.uk> <095F57A600314F7E86F6731FCC889A3D@masahiro> <87D23C72FA344A339A61EA9D3E333467@masahiro> <4AA0DFEB.2020800@dallaway.org.uk> <5D7EE4D955F443C7946FC40DB7EE93C1@masahiro> <4AA4EE58.2050100@dallaway.org.uk> <110701.39566.qm@web87005.mail.ird.yahoo.com> 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] cyg_scheduler_lock and DSR's X-SW-Source: 2009-09/txt/msg00097.txt.bz2 >>>>> "Jim" == Jim Bradleigh writes: Jim> Is the cyg_scheduler_lock() call not supposed to prevent Jim> DSR's from running? Yes, and no. Jim> I have a alarm, attached to the realtime clock which when Jim> activated posts a message to a custom queue system. This Jim> queue is also posted to by user land code.. Jim> Pushes to the queue are protected by a mutex. Additionally Jim> around the mutex I have the cyg_scheduler_lock() and Jim> cyg_scheduler_unlock() to prevent the DSR posting a message Jim> whilst inside the mutex operation. Jim> However I`m seeing asserts stating the mutex is already Jim> locked. A quick breakpoint and I can see that the DSR is Jim> still being called even after the lock() function.. The purpose of cyg_scheduler_lock() is to lock the scheduler, as the name implies. That means no other threads get to run while the current thread is runnable (on single-processor systems anyway, it gets a bit more complicated on SMP systems). A side effect of locking the scheduler is that DSRs cannot be allowed to run, because a DSR must run to completion and may manipulate the scheduler. However, if a thread locks the scheduler and then tries to claim a mutex that is already owned by another thread, things get more complicated. A strict interpretation of cyg_scheduler_lock() would mean that control cannot transfer to that or any other thread, so it would never get a chance to unlock the mutex, so the system would be deadlocked. Instead the correct interpretation of cyg_scheduler_lock() is that it locks the scheduler while, and only while, the calling thread is runnable. If the current thread becomes no longer runnable, e.g. because it tries to lock a mutex that is already owned or because it tries to wait on a synchronization object, then the current state of the scheduler lock is saved away, the thread suspends as normal, and other threads are allowed to run again. DSRs are allowed to run again as well - there is no reason not to and the alternative would introduce other possibilities for deadlock. Once the other thread releases the mutex and your thread gets to run again, the state of the scheduler lock gets restored so that the subsequent cyg_scheduler_unlock() does the right thing. I do not know the full details of your custom queue system. I suspect there is no need for the mutex lock at all - locking the scheduler provides all the required inter-thread synchronization to prevent concurrent access to the queue object, as well as blocking DSRs. If a mutex is still required for some reason, you'll probably want to lock the mutex first and then the scheduler, not the other way around. Bart -- Bart Veer eCos Configuration Architect eCosCentric Limited The eCos experts http://www.ecoscentric.com/ Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. >>>> Visit us at ESC-Boston http://www.embedded.com/esc/boston <<<< >>>> Sep 22-23 on Stand 226 at Hynes Convention Center, Boston <<<< -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss