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.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
