Re: how do I determine the number of active CPUs?

From: Kevin Easton (kevin_at_-nospam-pcug.org.au)
Date: 08/22/03 

Date: Fri, 22 Aug 2003 09:06:21 GMT

David Schwartz <davids@webmaster.com> wrote:
>
> "Kevin Easton" <kevin@-nospam-pcug.org.au> wrote in message
> news:newscache$4npwjh$5ti$1@tomato.pcug.org.au...
>
>> > Except 'sysconf' returns 1 when it can't tell how many CPUs you have.
>> > Very bad if you have both SMP-safe and SMP-unsafe code and are deciding
>> > which to use.
>
>> Userland code which is SMP-unsafe is also UP-unsafe, since threads may
>> be suspended and run at any point (userspace threads are preemptable). T
>> his is in contrast to kernel space code, which isn't preempted.
>
> Threads cannot be suspended and run at any time. In particular, they
> can't be suspended inside an instruction. It is trivial to write code that
> is SMP-unsafe but UP-safe. Here's an example (x86 Linux):
>
> #define LONG unsigned int
>
> typedef struct { volatile int c; } atom;
>
> LONG InterlockedIncrement(LONG *i)
> { // Add one to *i, return 0 if and only if *i is now 0
> unsigned char c;
> atom *a=(atom *) i;
> __asm__ __volatile__(
> "incl %1; setne %0"
> : "=qm" (c) // out
> : "m" (a->c) // in
> : "memory");
> return c;
> }
>
> The 'incl' instruction involves a read, an increment, and then a write.
> The thread cannot be pre-empted between the read and the subsequent write.
> However, on an SMP machine, the cache line can ping-pong between the read
> and the write. So this is user-space code that is UP-safe and SMP-unsafe.

OK, I didn't know that the atomicity of complex instructions like incl
was guaranteed with respect to interrupts. What about potentially
long-running REP prefixed instructions (are pending interrupts checked
at each iteration?).

        - Kevin.
 

Relevant Pages