Re: spin_lock_irqsave or spin_lock in work queue handlers?

[Lukas Razik <linux@xxxxxxxxxx>]

Hello Peter!


> > > 2 diff things.   semap are sync mechanism used - to sync among
> > > CPUs/processes/tasks etc.   Just a counting mechanism.   It DOES NOT
> > > lock the other CPU while another CPU is using the same resources.    but
> > > this counting must be atomic....different arch has different instruction
> > > set to do it.
> >
> > I thought that because there is an 'init_MUTEX(struct semaphore *)'
> > macro, there would be no difference between semaphores and mutex_locks.
> > So, did I understand it right:
> > semaphores are only local (for one CPU)?
> > mutex_locks also lock the other CPUs?
>
> all these API can affect other CPU's behavior.

What do you meen by "all these API"?
I thought the semaphores only affect the behavior of the local CPU...


> 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?


Regards and Thanks!
Lukas

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ