From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17377 invoked by alias); 15 Mar 2013 17:56:26 -0000 Received: (qmail 17369 invoked by uid 22791); 15 Mar 2013 17:56:25 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,KHOP_THREADED,NML_ADSP_CUSTOM_MED,SPF_NEUTRAL X-Spam-Check-By: sourceware.org Received: from sam.nabble.com (HELO sam.nabble.com) (216.139.236.26) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 15 Mar 2013 17:56:19 +0000 Received: from tom.nabble.com ([192.168.236.105]) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1UGYrb-00085O-67 for ecos-devel@ecos.sourceware.org; Fri, 15 Mar 2013 10:56:19 -0700 Date: Fri, 15 Mar 2013 17:56:00 -0000 From: jamescmaki To: ecos-devel@ecos.sourceware.org Message-ID: <1363370179179-225589.post@n7.nabble.com> In-Reply-To: <000901ce09de$3d3dc0d0$b7b94270$@cc> References: <000901ce09de$3d3dc0d0$b7b94270$@cc> Subject: Re: Cyg_Mutex::check_this() fails MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2013-03/txt/msg00001.txt.bz2 Hi Rene, At this point in the code the scheduler is not locked and the mutex is not owned. This means that it is a bad idea to be looking at the internal state of the mutex, i.e., calling CYG_ASSERTCLASS( mx, "Corrupt mutex"). I can reproduce this issue consistently now and I am testing a fix that changes CYG_ASSERTCLASS to CYG_ASSERT. I am hoping that this will resolve the problem instead of just moving the failed assert into Cyg_Mutex::lock(). However even if this does fix the problem, I am still wary. From what I can see, locked and owner are never modified without locking the scheduler. This means that they are both updated atomically. Because of this, when the thread in wait_inner() resumes it should see both of these variables in a consistent state regardless of whether it holds a lock or not. I am wondering if this can be explained by reordering and by delaying the check until the scheduler is locked again it avoids this problem. -James -- View this message in context: http://sourceware-org.1504.n7.nabble.com/Cyg-Mutex-check-this-fails-tp222044p225589.html Sent from the Sourceware - ecos-devel mailing list archive at Nabble.com.