[ECOS] suspend/resume nesting

sandeep sandeep@codito.com
Wed May 21 07:04:00 GMT 2003


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



More information about the Ecos-discuss mailing list