From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22158 invoked by alias); 27 Apr 2005 12:15:19 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 21698 invoked from network); 27 Apr 2005 12:14:42 -0000 Received: from unknown (HELO urano.sidsa.es) (195.53.86.130) by sourceware.org with SMTP; 27 Apr 2005 12:14:42 -0000 Received: from vega.sidsa.es ([195.53.86.229]) by urano.sidsa.es (8.12.10/) with ESMTP id j3RC9oZr011137 for ; Wed, 27 Apr 2005 14:09:50 +0200 Received: from localhost (localhost [127.0.0.1]) by vega.sidsa.es (Postfix) with ESMTP id 6B5311594E2 for ; Wed, 27 Apr 2005 14:10:46 +0200 (CEST) Received: from sidsa.es (unknown [195.53.86.231]) by vega.sidsa.es (Postfix) with ESMTP id A98BD1594E1 for ; Wed, 27 Apr 2005 14:10:45 +0200 (CEST) Message-ID: <426F8225.2050107@sidsa.es> Date: Wed, 27 Apr 2005 12:38:00 -0000 From: =?UTF-8?B?UnViw6luIFDDqXJleiBkZSBBcmFuZGEgQWxvbnNv?= Organization: SIDSA User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421 MIME-Version: 1.0 To: ecos-discuss@sources.redhat.com References: <426F4C4A.4020701@sidsa.es> <877jioipv1.fsf@osv.topcon.com> <426F5990.5060105@sidsa.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [ECOS] pthread_mutex_unlock when mutex is not locked X-SW-Source: 2005-04/txt/msg00278.txt.bz2 Ok, I understand you explain me. The standard also defines that a mutex locked by a thread must be unlocked by the same thread. However, many implementations of Pthreads allow use the mutex to signal events carring out lock and unlock of the mutex from different threads. But, ok, the DSR is not a thread :-). An example is the next code, that works with the POSIX compat layer of eCOS. N threads are created and executed in differents priority levels each one of them in SCHED_FIFO policy. The thread th(K) takes the priority equal to K and locks the pre-locked mutex m((K-1)%N). The th(K) also unlocks the mutex m(K) where the th(K+1) is waiting. So, because the Prio(th(K+1)) > Prio(th(K)) then the th(K+1) is dispatched at the same time that the th(K) unlocks the mutex m(K). #include #include #include #include #include #define STACK_SIZE (PTHREAD_STACK_MIN*2) #define NTHREADS 24 static pthread_t thread_id [NTHREADS]; static pthread_mutex_t mutex_id [NTHREADS]; static unsigned long thread_stk[NTHREADS][STACK_SIZE/sizeof(unsigned long)]; static profDeltaT_t clk_data [NTHREADS]; void *thread_fn (void *pdata) { long pre_index; pre_index = (((long)pdata-1) < 0)?(NTHREADS-1):((long)pdata -1); pthread_mutex_lock(&mutex_id[pre_index]); profGetHwClock(&(clk_data[pre_index].end)); profGetHwClock(&(clk_data[(long)pdata].start)); pthread_mutex_unlock(&mutex_id[(long)pdata]); pthread_exit(pdata); } int main (void) { long i; struct sched_param schedparam; pthread_attr_t pthattr; pthread_mutexattr_t mattr; pthread_mutexattr_init( &mattr ); schedparam.sched_priority = NTHREADS+2; pthread_setschedparam(pthread_self(), SCHED_FIFO, &schedparam); pthread_attr_init(&pthattr); pthread_attr_setinheritsched(&pthattr, PTHREAD_EXPLICIT_SCHED); pthread_attr_setschedpolicy(&pthattr, SCHED_FIFO); pthread_attr_setdetachstate(&pthattr, PTHREAD_CREATE_JOINABLE); pthread_attr_setstacksize(&pthattr, STACK_SIZE); for (i = 0; i < NTHREADS; i++) { pthread_mutex_init(&mutex_id[i], &mattr); pthread_mutex_lock(&mutex_id[i]); } profWait4Tick(); for (i = 0; i < NTHREADS; i++) { pthread_attr_setstackaddr(&pthattr, &thread_stk[i][STACK_SIZE/sizeof(unsigned long)]); schedparam.sched_priority = i+1; pthread_attr_setschedparam(&pthattr, &schedparam); pthread_create(&thread_id[i], &pthattr, thread_fn, (void *)i); } profGetHwClock(&(clk_data[NTHREADS-1].start)); pthread_mutex_unlock(&mutex_id[NTHREADS-1]); for (i = 0; i < NTHREADS; i++) { pthread_join(thread_id[i], NULL); } printf("\n" " POSIX LAYER TEST 1: switch thread context\n" " when control is transfered through mutexes\n" "\n" ); profPrintData((profDeltaT_t*)clk_data, NTHREADS-1, printf); return 0; } Anothe cuestion. Can I use the next code to guaratee the mutual exclusion in access to critical data from a thread and a DSR? DSR () { if (pthread_mutex_trylock(&mutex) == 0) { // Access to data // Calculate ..... // Unlock pthread_mutex_unlock(&mutex); } } Thnak you very much Nick Garnett wrote: >Rubén Pérez de Aranda Alonso writes: > > > >>I think the mutex is appropiate for the explained scenario. >> >>The standard says: >>"If the mutex type is PTHREAD_MUTEX_RECURSIVE, then the mutex >>maintains the concept of a lock count. When a thread successfully >>acquires a mutex for the first time, the lock count is set to >>one. Every time a thread relocks this mutex, the lock count is >>incremented by one. Each time the thread unlocks the mutex, the lock >>count is decremented by one. When the lock count reaches zero, the >>mutex becomes available for other threads to acquire. If a thread >>attempts to unlock a mutex that it has not locked or a mutex which is >>unlocked, an error will be returned." >> >>http://www.opengroup.org/onlinepubs/007908799/xsh/pthread_mutex_lock.html >> >>So, I think the unlock method must return an error code. In eCOS, this >>method returns void. If we check the mutex is locked at least we avoided the >>crash of the system. >> >> > >eCos doesn't currently support recursive mutexes -- partly because >some of us consider them the work of the devil and partly because it >would require some significant work on the kernel mutex code to make >it work smoothly with the priority inversion protocols. > >DSRs are not threads, and can be called in the context of any thread >in the system. Calling mutex unlock from a DSR would do it in the >context of the thread that happened to running when the interrupt >occured. If you are lucky, this will be the thread that locked the >mutex and it will work. If you are unlucky, it will be a different >thread and the mutex will not get unlocked. > >Condition variables can be signalled from DSRs and you should really >use one of those to wake up any threads. > > > > -- ______________________________________________________________ Rubén Israel Pérez de Aranda Alonso SIDSA - Semiconductores Investigación y Diseño S.A. Parque Tecnológico de Madrid Phone : +34 91 803 5052 C/ Torres Quevedo, nº 1 Fax: +34 91 803 9557 28760 TRES CANTOS (Madrid) (SPAIN) e-mail: rperez@sidsa.com www.sidsa.com ______________________________________________________________ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss