Re: [ECOS] question on eCos mutex behavior

[Andrew Lunn <andrew at lunn dot ch>]

On Wed, Apr 25, 2007 at 01:39:39PM -0600, Gary Thomas wrote:
> David Hill wrote:
> >Hi.
> >
> >I'm experiencing some unexpected behavior using mutexes under eCos and I'm 
> >wondering if this is just the way it works or if I might be missing 
> >something.  I created a simple test case below to illustrate the behavior 
> >- I have two threads that are both running at the same priority and always 
> >trying to get a mutex lock.  The only difference between them is that I 
> >guaranteed that the first would win the first time by inserting an 
> >artificial delay into the 2nd thread. I expected that when the 1st thread 
> >unlocks the mutex, and tries to take it again, the cyg_mutex_lock() 
> >function would hang because there is already another thread pending on 
> >that mutex.  However, what I'm seeing is that the 1st thread continues to 
> >succeed over and over again and the 2nd thread gets starved, so I see lots 
> >of "LOCK0" statements and no "LOCK1" statements.  If I uncomment the 
> >'cyg_thread_delay(1)' statement after the mutex is unlocked, then I get 
> >the nice ping-pong effect I was expecting, but I can't
> really use that workaround for my application.
> >
> >If this is expected behavior, then is there a different mutual exclusion 
> >primitive that will provide ordering?
> >
> >If this is unexpected behavior, then are there some kernel parameters that 
> >might explain this?
> >
> >Thanks,
> >Dave Hill
> >AirDefense, Inc.
> >
> >
> >static cyg_mutex_t         TestMutex;
> >
> >static void testthread(cyg_addrword_t param)
> >{
> >    if (param == 0)
> >    {
> >        cyg_mutex_init(&TestMutex) ;
> >    }
> >    else
> >    {
> >        cyg_thread_delay(50);
> >    }
> >
> >    while (cyg_mutex_lock(&TestMutex) == true)
> >    {
> >        diag_printf("LOCK%d\n", (int)param);
> >        cyg_thread_delay(100);
> >        cyg_mutex_unlock(&TestMutex);
> >//        cyg_thread_delay(1);
> >    }
> >
> >}
> >
> >static void startTestThread(int num, uint8_t *stack,
> >                            uint16_t stacksize, cyg_thread *threadData)
> >{
> >    cyg_handle_t handle;
> >    cyg_thread_create(10,
> >                      testthread,
> >                      num,
> >                      "tt",
> >                      stack,
> >                      stacksize,
> >                      &handle,
> >                      threadData);
> >    cyg_thread_resume(handle);
> >}
> >static void cliTestMutexCmd(int socket, CLI_INPUT *in)
> >{
> >    static uint8_t stack1[1024];
> >    static uint8_t stack2[1024];
> >    static cyg_thread thread1;
> >    static cyg_thread thread2;
> >
> >    startTestThread(0, stack1, 1024, &thread1);
> >    startTestThread(1, stack2, 1024, &thread2);
> >}
> >
> >
> 
> Look carefully at your code - the second thread is most
> likely going to enter, then try to get the mutex which
> will fail and then exit.  No more second thread, thus
> no "LOCK1" messages.

Hi Gary.

I don't follow what you are saying. cyg_mutex_lock only fails if
cyg_mutex_release or cyg_thread_release is called. So i don't see why
the whole loop should exit with this code.

    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