lkml.org 
[lkml]   [2005]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Add support for semaphore-like structure with support for asynchronous I/O
    On Thu, Apr 07, 2005 at 12:43:02PM +0100, Christoph Hellwig wrote:
    > - switch all current semaphore users that don't need counting semaphores
    > over to use a mutex_t type. For now it can map to struct semaphore.
    > - rip out all existing complicated struct semaphore implementations and
    > replace it with a portable C implementation. There's not a lot of users
    > anyway. Add a mutex_t implementation that allows sensible assembly hooks
    > for architectures instead of reimplementing all of it
    > - add more features to mutex_t where nessecary

    Oh dear, this is going to take a while. In any case, here is such a
    first step in creating such a sequence of patches. Located at
    http://www.kvack.org/~bcrl/patches/mutex-A0/ are the following patches:

    00_mutex.diff - Introduces the basic mutex abstraction on top
    of the existing semaphore implementation.
    01_i_sem.diff - Converts all users of i_sem to use the mutex
    abstraction.
    10_new_mutex.diff - Replaces the semphore mutex with a new mutex
    derrived from Trond's iosem patch. Note that
    this fixes a serious bug in iosems: see the
    change in mutex_lock_wake_function that ignores
    the return value of default_wake_function, as
    on SMP a process might still be running while
    we actually made progress.
    sem-test.c - A basic stress tester for the mutex / semaphore.

    I'm still not convinced that introducing the mutex type is the best
    approach, especially given the history of the up()/down() implementation.

    On the aio side of things, I introduced the owner field in the mutex (as
    opposed to the flag in Trond's iosem) for the next patch in the series to
    enable something like the following api:

    int aio_lock_mutex(struct mutex *lock, struct iocb *iocb);

    ...generic_file_read....
    {
    ret = mutex_lock_aio(&inode->i_sem, iocb);
    if (ret)
    return ret; /* aio_lock_mutex can return -EIOCBQUEUED */
    ...
    mutex_unlock(&inode->i_sem);
    }

    mutex_lock_aio will attempt to take the lock if the iocb is not the owner,
    otherwise it returns immediately (ie ->owner == iocb). This will allow for
    code paths that support aio to follow a fairly similar coding style to the
    synchronous io path.

    More next week...

    -ben
    --
    "Time is what keeps everything from happening all at once." -- John Wheeler
    -
    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-09 00:45    [W:0.021 / U:148.444 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site