[ECOS] pthread_mutex_unlock when mutex is not locked

[ECOS] pthread_mutex_unlock when mutex is not locked

[Rubén Pérez de Aranda Alonso]

Hi all,
I have found a problem when I want to unlock a mutex that is not locked
by any thread. This scenario can be needed when we want to signal
a resource in hardware is free from a DSR, that is executed by a
peripheral interrupt, to threads that requires the access to this
resource. The thread will execute a lock before access to resource.
The DSR will be executing an unlock for each HW interrupt although
there aren't threads accessing to the resource.
I think the mutex must verify the lock condition before perform
an unlock operation.
I have added the next code in Cyg_Mutex::unlock(void) method:

void
Cyg_Mutex::unlock(void)
{
    CYG_REPORT_FUNCTION();
    // ---------------------
    if (!locked)
    {
        CYG_INSTRUMENT_MUTEX(UNLOCK, this, 0);
        CYG_REPORT_RETURN();
        return;
    }
    // ---------------------
       
[...]


This scenario can also be solved using message queues or semaphores.
I prefer mutexes because the unlock condition is when their count
is equal to zero, and, in semaphores, the unlock condition is when
their count is > 0.

Regards,

Rubén

-- 
______________________________________________________________

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

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Sergei Organov]

Rubц╘n Pц╘rez de Aranda Alonso <rperez@sidsa.es> writes:
> Hi all,
> I have found a problem when I want to unlock a mutex that is not locked
> by any thread.

Then the problem is in your code. The mutex is not appropriate for what
you are doing, -- only the thread that locked the mutex is allowed to
unlock it. Use something else, e.g., semaphore or condition variable to
achieve your goal.

-- 
Sergei.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Rubén Pérez de Aranda Alonso]

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.

Rubén

Sergei Organov wrote:

>RubИn PИrez de Aranda Alonso <rperez@sidsa.es> writes:
>  
>
>>Hi all,
>>I have found a problem when I want to unlock a mutex that is not locked
>>by any thread.
>>    
>>
>
>Then the problem is in your code. The mutex is not appropriate for what
>you are doing, -- only the thread that locked the mutex is allowed to
>unlock it. Use something else, e.g., semaphore or condition variable to
>achieve your goal.
>
>  
>


-- 
______________________________________________________________

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

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Andrew Lunn]

On Wed, Apr 27, 2005 at 11:21:20AM +0200, Rub??n P??rez de Aranda Alonso wrote:
> 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."

And the next paragraph says:

If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively
lock the mutex results in undefined behaviour. Attempting to unlock
the mutex if it was not locked by the calling thread results in
undefined behaviour. Attempting to unlock the mutex if it is not
locked results in undefined behaviour.

Have you configured the mutex to be PTHREAD_MUTEX_RECURSIVE?  I guess
not. I would call a crash an undefined behavour, so i think its OK
according to the second paragraph.

Also, a DSR is not a thread. The paragraph you quoted always talks
about threads.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Nick Garnett]

Rubén Pérez de Aranda Alonso <rperez@sidsa.es> 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.


-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Sergei Organov]

Rubц┐б╘n Pц┐б╘rez de Aranda Alonso <rperez@sidsa.es> 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."

1. Nowhere in your original post did you've mention you use POSIX mutexes. 

2. Nowhere in the POSIX documents you will find anything about DSRs, so
   semantics of calling mutex operations from DSRs aren't defined by
   POSIX.

-- 
Sergei.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Rubén Pérez de Aranda Alonso]

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 <stdlib.h>
#include <stdio.h>
#include <pthread.h>
#include <sched.h>

#include <prof.h>


#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 <rperez@sidsa.es> 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

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Sergei Organov]

Rubц┐б╘n Pц┐б╘rez de Aranda Alonso <rperez@sidsa.es> writes:
> 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.

Really? The mutex is invented for what it is in it's name: "MUTual
EXclusion". You definitely can abuse implementation details that make
some code work on some implementations, but isn't it better to use
the right tool instead?

That said, there is nothing wrong with semantic of mutexes in eCos.

-- 
Sergei.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Rubén Pérez de Aranda Alonso]

Ok, I agree.

Sergei Organov wrote:

>Rubц╘n Pц╘rez de Aranda Alonso <rperez@sidsa.es> writes:
>  
>
>>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.
>>    
>>
>
>Really? The mutex is invented for what it is in it's name: "MUTual
>EXclusion". You definitely can abuse implementation details that make
>some code work on some implementations, but isn't it better to use
>the right tool instead?
>
>That said, there is nothing wrong with semantic of mutexes in eCos.
>
>  
>


-- 
______________________________________________________________

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

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Nick Garnett]

Rubén Pérez de Aranda Alonso <rperez@sidsa.es> writes:

> 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.

Such implementation are broken in that case. It is not even clear how
such an implementation could handle priority inheritance correctly.

> 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).

Sorry, but this program totally violates the intended and documented
way in which mutexes should be used.

> 
> 
> 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);
>   }
> }

That is not guaranteed to work. Posix threads have additional data
attached to them, which is absent in non-Posix threads. Any
Posix functions called in a DSR may try to access this extra data. If
it is not a Posix thread then the access will fail, or attempt to
access invalid memory.

ISRs and DSRs are not part of the Posix secification, any attempt to
use Posix calls in these contexts in undefined. Instead you should be
using the eCos API, specifically the cyg_drv_* routines defined in the
driver API.

-- 
Nick Garnett                                     eCos Kernel Architect
http://www.ecoscentric.com                The eCos and RedBoot experts


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] pthread_mutex_unlock when mutex is not locked

[Rubén Pérez de Aranda Alonso]

Nick Garnett wrote:

>Rubén Pérez de Aranda Alonso <rperez@sidsa.es> writes:
>
>  
>
>>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.
>>    
>>
>
>Such implementation are broken in that case. It is not even clear how
>such an implementation could handle priority inheritance correctly.
>  
>
>>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).
>>    
>>
>
>Sorry, but this program totally violates the intended and documented
>way in which mutexes should be used.
>  
>
I know it. In my firmware design I don't use things like this.  It only 
is an
example that works fine in my platform.

>  
>
>>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);
>>  }
>>}
>>    
>>
>
>That is not guaranteed to work. Posix threads have additional data
>attached to them, which is absent in non-Posix threads. Any
>Posix functions called in a DSR may try to access this extra data. If
>it is not a Posix thread then the access will fail, or attempt to
>access invalid memory.
>
>ISRs and DSRs are not part of the Posix secification, any attempt to
>use Posix calls in these contexts in undefined. Instead you should be
>using the eCos API, specifically the cyg_drv_* routines defined in the
>driver API.
>
>  
>
Ok, Posix doesn't define any thing about interrupts behaviour and handling,
but I prefer use Posix API to make easy the port of code in the future, 
from eCOS
to other RTOS. This scheme of trylock-unlock in DSRs works fine in my
firmware, although I will think about you explain me to find another 
solution
based on Posix API but using a little part of eCOS API to allow the mutual
exclusion between the threads and the DSRs.


Than you


Rubén


-- 
______________________________________________________________

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