its the synopsis that u made legend for ...and yes it contains 1:1 copies but as i already said in post89641 that its 
work done in WIN XP using JAVA and i want to implement in QNX  which is not previously done ...
so i disagree that its" Academically, very bad style"..

After your explanation abt my present  approach ..
1] it might be or look now a wrong way to achive the objectives 
     but i hve left with no choice as i cant have access to process &  memory manager code or kernel code...as u said the change in Kernel might work.

2] so ,as  i said i am stimulating this approach what the Helmy & Jafri did (stimulation) for WIN XP..i made phone calls to these authors which found :( ...


Thanks &  Regards,
 Atul Kumbhar







 
> I took the freedom to read your document, do a 
tiny bit of research and 
> highlight all those passages in your paper that are 1:1 copies of other 
> sources (see below for a legend) without being denoted as such. Not counting 
> the impressive title page and your project plan, I found exactly ten (10) 
> words that appeared to be written by you, plus three new literature references
>  not used anywhere in your paper. Academically, very bad style. 
> 
> I do assume, though, that you read enough of what you *ahem* cited to enagage 
> in a discussion of your proposed approach:
> 
> First, as you said yourself, a resource-restitution mechanism will by far not 
> work for all types of resources. In fact, it could safely work only with 
> 'simple' shared memory - not with devices, not with kernel objects like 
> mutexes etc., and also not with memory that could be accessed by other 
> processes or devices than the ones involved in your synchronization.
> 
> Second, a resource manager will not be able to deliver the functionality you 
> are looking to implement; the resource-manager framework itself is based upon 
> message-passing (see QNX Neutrino Architecture) which merely takes your trying
>  to avoid priority inheritance to a second dimension.
> To really deliver the desired functionality, you'd need to extend the kernel, 
> such that backup copies of synchronized data could be taken atomically and 
> threads could be reset if necessary.
> But even then, it wouldn't help. Consider this scenario with two threads, TL (
> low) and TH (high priority):
> 
> * TL runs, enters synchronized section
> * Backup is taken
> * A signal is delivered to TL, causing some action
> * TH gets running, preempts TL and enters the synchronized section
> * Backup is restored and TL is re-set to beginning of sync section
> * TH blocks
> * TL re-runs the sync section, this time without the signal
> 
> 
> As for the cited criticism of priority inheritance (or, to use the dedicated 
> QNX term for this case, priority boost):
> * The nested critical regions protected by priority inheritance locks generate
>  long inversion delays.
> The prerequisite for this to happen is that when TH waits for a lock held by 
> TL, TL in turn wants to acquire another lock currently held by yet another 
> thread. In real life, you'll aim to avoid this and keep critical sections 
> _short_.
> 
> * Priority inheritance fails if tasks mix inheriting and non-inheriting 
> operations.
> Of course. A helmet fails to protect my head if I take it off.
> 
> * Priority inheritance worst case performance is worse than the easy 
> alternatives in most cases.
> Victor Yodaiken, author of the nice paper "Against priority inheritance" 
> containing this and the other arguments against priority inheritance, suggests
>  to "disable preemption" [during critical sections] as a viable and fast 
> alternative. Great. That way we're back to priority inversion again.
> 
> * Inheritance algorithms are complicated and easy to...