lkml.org 
[lkml]   [2005]   [Apr]   [18]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
    /
    DateSun, 17 Apr 2005 22:30:42 -0700
    SubjectRe: FUSYN and RT
    FromBill Huey (hui) <>
    On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
    > By following your method, the pi engine becomes unnecesarily complex;
    > you have actually two engines following two different propagation
    > chains (one kernel, one user). If your mutexes/locks/whatever are the
    > same with a different cover, then you can simplify the whole
    > implementation by leaps.
    
    The main comment that I'm making here (so it doesn't get lost) is that,
    IMO, you're going to find that there is a mismatch with the requirements
    of Posix threading verse kernel uses. To drop the kernel mutex in 1:1 to
    back a futex-ish entity is going to be problematic mainly because of how
    kernel specific the RT mutex is (or any future kernel mutex) for debugging,
    etc... and I think this is going to be clear as it gets progressively
    implemented.
    
    I think folks really need to think about this clearly before moving into
    any direction prematurely. That's what I'm saying. PI is one of those
    issues, but ultimately it's the fundamental differences between userspace
    and kernel work.
    
    LynxOS (similar threading system) keep priority calculations of this kind
    seperate between user and kernel space. I'll have the ask one of our
    engineers here why again that's the case, but I suspect it's for the
    reasons I've discussed previously.
    
    bill
    
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    
    
    \
     
     \ /
      Last update: 2005-04-18 07:34    [from the cache]
    ©2003-2008