This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: suspend/resume nesting
- From: sandeep <sandeep at codito dot com>
- To: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>
- Cc: "ecos-discuss (E-Mail)" <ecos-discuss at sources dot redhat dot com>
- Date: Wed, 21 May 2003 12:44:34 +0900
- Subject: Re: [ECOS] suspend/resume nesting
- References: <850597605E79D21182830008C7A4B9CF1EB425D0@COMM1>
hi tk,
With the curent implementation, this scheme will only work if
A's priority is greater than B's. If it's the other way round,
B will run before A gets a chance to suspend itself, and B's
attempt to resume A will have no effect, resulting in a deadlock
when A finally runs again and calls suspend() for itself.
>
> As I said, this kind of behavior is highly undesirable, as it
> makes the outcome of the above scenario dependent on the relative
> priorities of the threads involved, or even toally non-deterministic
> on SMP hardware. It also makes a difference whether the higher priority
> thread ever enters a wait state before it resumes its companion, or
> not.
>
what about following solution to your requirements (for sake of simplicity
sched_lock is initially chosen to be 0, though it could be any other non-zero
value too, except that in that case unlock_inner will be called later, when
sched_lock goes 0) --
[sched_lock = 0]
<i> A takes schedular_lock
[sched_lock = 1]
<ii> A invokes resume for B [sched_lock goes 1->2->1 in this call]
[sched_lock = 1]
<iii> A invokes suspend for itself [sched_lock goes 1->2->1 in this call]
[sched_lock = 1]
<iv> A releases schedular_lock
[sched_lock goes to 0 resulting in call to unlock_inner causing A to be taken
off and B to be brought in]
exchange positions of A and B in above explanation and you will get what you
will need to do on B's side.
regards
sandeep
--
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss