I just found more information. There is a whole movement of converting semaphore to mutex in the kernel. One active contributor is "Daniel Walker", search for patch like "printer port driver: semaphore to mutex" etc. And the explanation (which is the only I can find, still cannot explain very well the reason for the conversion IMHO) is contained in Documentation/mutex-design.txt). But this documentation also mentioned a lot of the dos and dont' about mutex.....read it....very informative. On Thu, Mar 6, 2008 at 9:50 PM, Lukas Razik <linux@xxxxxxxxxx> wrote: > Hello again! > > > > >> > mutex does not "lock" in the sense of blocking the CPU - but in the > >> > sense that if the lock is not free, the task will be switch out and > >> > another task switch in, done by scheduler. > >> > >> O.K. I understand so I ask in another way: > >> For example my work handler is running on CPU0 and holds the mutex_lock. > >> Then (on CPU1) my work handler also calls mutex_lock. > >> Will it "see" that the lock is held by the work handler on CPU0 and will > >> it be switched out by the scheduler? > >> > > > > > > I think one answer can answer both question: Generally, all locking > > API always work on global variable. Global variable means the entire > > linux kernel only have one copy of the variable. For eg, for varA all > > spinlock(varA) are basically holding on the same variable - the same > > copy in memory. > > > > There is no meaning of individual CPU have their own private variable > > - individually whatever they do, is not visible to the other CPU, so > > what is the purpose of locking? > > > > Yes, all API means semaphore/mutex/spinlocks. > > > > O.K. So I use mutex_locks now. > Many Thanks for the information and your patience! > > Regards, > Lukas > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
