Hi Joonwoo, I think it doesn't matter whether the filp is shared by multiple threads or not. The mutex is only protecting the assignment, and the assignment can differ only in the least-significant bit. No matter how many threads call at once, the stored value will be valid. There's a race condition as to which thread wins, but that's true even with the mutex.
Regards, BBL --- On Wed, 2/2/11, Joonwoo Park <[email protected]> wrote: > From: Joonwoo Park <[email protected]> > Subject: Re: [Click] click Digest, Vol 92, Issue 4 > To: "Bobby Longpocket" <[email protected]> > Cc: [email protected] > Date: Wednesday, February 2, 2011, 11:20 AM > Bobby, > > On Wed, Feb 2, 2011 at 11:04 AM, Joonwoo Park <[email protected]> > wrote: > >> In ToUserDevice: It looks like the existing > IOCTL isn't doing anything that requires locking, so you > should be able to leave out the mutex. > > > > I don't think so... filp->private_data is not > atomic on every platform. > > > > I have to double check tonight (I'm not accessing click > source code at > work) but I think it's possible I was wrong. > I was thinking that filp->private_data is shared between > different > userspace open. But it's probably not true. > I'll have look again. > > Thanks! > Joonwoo > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
