Dear all,a few consideration on the BWI scheme, that was mentioned by Peter and by Raistlin a few messages ago. I do not know very well the PEP scheme, from the discussion until now the basic idea looks pretty similar to our protocol. The BWI is described in this paper:[1] http://feanor.sssup.it/~lipari/papers/rtss2001-bwi.ps.gz(I just removed the password, feel free to download it, I hope IEEElawyers will not chase me!).In essence, when a task is blocked on a lock, its budget may beconsumed by the task holding the lock. A task can be assigned one ormore pairs (budget,deadline), one is its original one, the others are"inherited" when holding a lock on which other tasks are blocked.This scheme has advantages and disadvantages.  The advantages are:1) Isolation. It is easy to see that the budget of a task can bestolen only by tasks that share common locks, directly orindirectly. For the sake simplicity, consider only non nestedlocks. If two tasks A and B do not share any lock, then they cannotinfluence each other. (In the paper, this property is generalized tonested locks).  This property is useful if we want to isolate thebehavior of one (group of) task(s) from the others. For example, a"hard real-time" task (group) must be isolated from soft real-timetasks.  Under EDF other classical protocols (like PI, SRP) do not havethe same property, because letting a task use a critical section forlonger than expected can jeopardize the schedulability of the anyother tasks.2) Simpler admission test. With other schemes (PI, SRP), it isnecessary to compute blocking times for all tasks, which depend on thelength of the critical sections.  The blocking times are then used inthe admission test formula. However, if one blocking time is wronglycalculated, at run-time any task can miss its deadline. With BWI,instead, the admission test is the simpler \sum U_i \leq 1, anddoesnot depend on the length of the critical section.3) Under the assumption that tasks do not block inside a criticalsection, BWI can be implemented in a fairly simple way.4) It is indeed possible (under certain conditions) to verify theschedulability of a hard real-time task H by knowing the length of allcritical sections of all tasks that share some lock with H. The verycomplex procedure is explained in the paper.However, BWI has some disadvantages1) It is only for single processors.2) From a schedulability point of view, if we want to guarantee thatevery task always respects its deadline, when computing its budget wemust calculate the "interference" of other tasks. Since, we have to dothis for every "hard" task, we may end up counting the same criticalsection several times, thus wasting some bandwidth.  This is betterexplained in the paper (section 6.4.1).3) If a task is allowed to block in the middle of a critical section(for example, due to a page fault), the implementation becomes muchmore complex.Concerning point 1, as Raistlin pointed out (see its e-mails), he isworking on extending BWI to multiprocessors, also from a theoreticalpoint of view. It is possible that the result will be similar to theone obtained by the Dougleas Niehaus with PEP. We hope he will be ableto add some "theoretical spice"!Concerning point 2, this cannot be avoided. We believe that BWI isuseful for open systems (where tasks are created/killed dynamically)and for soft real-time systems. However, under certain conditions, itallows to schedule and analyse hard real-time tasks, even when mixedwith soft real-time tasks.Concerning point 3, this is the most difficult point. In fact,achieving an efficient implementation in this case seems veryunlikely. However, we believe that blocking inside a critical sectionit is probably a rare event, and then maybe it is possible to affordsome extra overhead in such unfortunate cases.I hope I clarified some obscure issues with BWI! Regards,Giuseppe Liparibegin:vcardfn:Giuseppe Liparin:Lipari;Giuseppeemail;internet:giuseppe.lipari@sssup.ittel;work:+39 050882030tel;fax:+39 050882003tel;cell:+39 3480718908version:2.1end:vcard