public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* SMP share data declaration
@ 2006-07-14  2:58 wyb
  2006-07-14  8:48 ` Jesper Juhl
  0 siblings, 1 reply; 3+ messages in thread
From: wyb @ 2006-07-14  2:58 UTC (permalink / raw)
  To: linux-kernel

I know that an integer variable should be declared volatile to share between
CPUs.
But for more complicated variable, I don't know if it should be volatile.
for example:

linux-2.6.6/kernel/workqueue.c:
struct workqueue_struct *__create_workqueue(const char *name,int
singlethread)
{
    ...
    if (singlethread) {
        ...
    } else {
        spin_lock(&workqueue_lock);
        list_add(&wq->list, &workqueues);
        spin_unlock_irq(&workqueue_lock);
        ...
    }
    ...
}

workqueues is a none volatile list_head. The spin_lock/unlock act as memory
barrier, so gcc flush any register cached value to memory. But if another
CPU allocate workqueues.next/prev in registers, how to make sure this cpu
get new value ?

static int __devinit workqueue_cpu_callback(struct notifier_block *nfb,
      unsigned long action,
      void *hcpu)
{
    ...
    switch (action) {
    case CPU_UP_PREPARE:
    /* Create a new workqueue thread for it. */
    list_for_each_entry(wq, &workqueues, list) {
        ...
}

how to make sure workqueue_cpu_callback() get new value ?

thanks very much



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: SMP share data declaration
  2006-07-14  2:58 SMP share data declaration wyb
@ 2006-07-14  8:48 ` Jesper Juhl
  2006-07-14 11:31   ` Hannibal B
  0 siblings, 1 reply; 3+ messages in thread
From: Jesper Juhl @ 2006-07-14  8:48 UTC (permalink / raw)
  To: wyb@topsec.com.cn; +Cc: linux-kernel

On 14/07/06, wyb@topsec.com.cn <wyb@topsec.com.cn> wrote:
> I know that an integer variable should be declared volatile to share between
> CPUs.

NO. volatile won't protect you sufficiently.

Use spinlocks, mutexes, semaphores, barriers and the like to protect
variables from concurrent access. Using volatile for this is a BUG and
it won't work correctly.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE: SMP share data declaration
  2006-07-14  8:48 ` Jesper Juhl
@ 2006-07-14 11:31   ` Hannibal B
  0 siblings, 0 replies; 3+ messages in thread
From: Hannibal B @ 2006-07-14 11:31 UTC (permalink / raw)
  To: Jesper Juhl, wyb; +Cc: linux-kernel

Spinlocks would be the one to protect the variable and synchronies
between CPU, But it's a busy waiting mechanism(just a word of caution).
Regards,
Hannibal

-----Original Message-----
From: Jesper Juhl [mailto:jesper.juhl@gmail.com] 
Sent: Friday, July 14, 2006 2:18 PM
To: wyb@topsec.com.cn
Cc: linux-kernel@vger.kernel.org
Subject: Re: SMP share data declaration

On 14/07/06, wyb@topsec.com.cn <wyb@topsec.com.cn> wrote:
> I know that an integer variable should be declared volatile to share
between
> CPUs.

NO. volatile won't protect you sufficiently.

Use spinlocks, mutexes, semaphores, barriers and the like to protect
variables from concurrent access. Using volatile for this is a BUG and
it won't work correctly.


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html
-
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/



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-07-14 12:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-14  2:58 SMP share data declaration wyb
2006-07-14  8:48 ` Jesper Juhl
2006-07-14 11:31   ` Hannibal B

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox