This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: suspend/resume nesting


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]