On Thu, Mar 6, 2008 at 6:00 PM, Lukas Razik <linux@xxxxxxxxxx> wrote:
> Hello Peter!
>
>
> > Sorry, I missed the question onf the CONFIG_TRACE_IRQFLAGS - I think
> > that config option is meant for tracing the IRQ flow in the event of
> > debugging. Correct?
>
> O.K. So it's only a help for debugging...
>
>
>
> >> I use semaphores now (down() and up()). And the interface doesn't seem
> >> to be slower. Is that also O.K.?
> >> I don't know mutex_lock. What's the difference between mutex_locks and
> >> semaphores? Is it better to use mutex_locks here?
> >>
> >>
> > 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.
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.
>
>
> > sometime the kernel guarantee the atomicity by putting a
> > spin lock around it.
> > Take a look at the fs/super.c code - mutex is
> > often used TOGETHER with the semaphore.
> >
> > static int grab_super(struct super_block *s) __releases(sb_lock)
> > {
> > s->s_count++;
> > spin_unlock(&sb_lock);
> > down_write(&s->s_umount);
> > if (s->s_root) {
> >
> > Or this:
> >
> > void unlock_super(struct super_block * sb)
> > {
> > put_fs_excl();
> > mutex_unlock(&sb->s_lock);
> > }
> >
>
> I see.
>
>
>
> > (in general all the get_xxx and put_xxx functions u see in the source
> > code are semaphore - sorry if this generalization is wrong :-)). They
> > goes in pair to ensure balance in counting. but u used semaphore ONLY
> > WHEN u want to have multiple user sharing the same resources. eg, one
> > data, many reader, but writer u can only have one - so semaphore cannot
> > be used here - either spin lock or mutex solely.
>
> O.K. but is there something I can use if I have for example one writer
> and many readers on _different_ CPUs?
>
This is the classic scenario of RCU: each CPU will maintain a
structure to keep a version of its own value, without another writer
affecting it. The writer will be writing to another version of the
variable, fine, but since each CPU have their own individual
consistent version (which may be different on diff CPU) it is fine, as
they are only interested in reading and not modifying it.
>
>
> > have u heard of lockfree/waitfree algorithm (check wiki)? or
> > non-blocking synchronization? (linux call it RCU - check wiki, and
> > under Documentation/RCU directory in source). It is a large topic
> > itself....i cannot justify to describe it here.....type "lockfree" in
> > google video and u can listen to a seminar on this
> > algorithm.....wow...google video has lots of open source seminar btw.
>
> I haven't heard about these algorithms. I've read the wiki entry but I
> will look for more information about this topic.
>
--
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
