From: Andrew Lunn <andrew@lunn.ch>
To: Gary Thomas <gary@mlbassoc.com>
Cc: David Hill <DHill@airdefense.net>, ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] question on eCos mutex behavior
Date: Wed, 25 Apr 2007 20:37:00 -0000 [thread overview]
Message-ID: <20070425203706.GB4336@lunn.ch> (raw)
In-Reply-To: <462FAE7B.9020702@mlbassoc.com>
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
next prev parent reply other threads:[~2007-04-25 20:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-25 19:21 David Hill
2007-04-25 19:39 ` Gary Thomas
2007-04-25 20:37 ` Andrew Lunn [this message]
2007-04-25 20:51 ` Andrew Lunn
2007-04-25 21:08 ` David Hill
2007-04-25 21:28 ` Andrew Lunn
2007-04-26 9:44 ` Nick Garnett
2007-04-25 21:17 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070425203706.GB4336@lunn.ch \
--to=andrew@lunn.ch \
--cc=DHill@airdefense.net \
--cc=ecos-discuss@ecos.sourceware.org \
--cc=gary@mlbassoc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).