Re: Not able to generate race condition... please help

[seshikanth varma <seshikanthvarma@xxxxxxxxx>]

This sounds good. My kernel is not SMP. Then to try some experiments on this concept of automicity and how the threads are affected with this, is there any way to simulate SMP kernel. I mean, i want to use my kernel as

option 1: non SMP

option 2: SMP

by specifiing the options...

Else is there any way of simulating the non-automicity with single core (Any wrappers to do this)? 

Thanks,

Seshikanth

On Fri, May 8, 2009 at 11:29 AM, sandeep lahane <sandeep.lahane@xxxxxxxxx> wrote:

On Fri, May 8, 2009 at 10:40 AM, Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx> wrote:

On Fri, May 8, 2009 at 11:46 AM, mukti jain <muktijn@xxxxxxxxx> wrote:
> Hi Seshi,
>

>  I  suppose  race is generated with  LOOPCONSTANT = 100000,
>  Actually for race  on the variables the threads need to be scheduled in the
> middle of updating the variables.
>  So you should do some minimum  work  in the thread function so other
> threads get chance to run.

Uhm, could it be because it's "int"? integer, AFAIK, at least in x86
32 bit, is updated atomically.

regards,

Mulyadi.

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

IMHO, you are not seeing any race since you are accessing 'volatile integers' on a non SMP machine.
AFAIK, accesses to types smaller than or equal to native pointer size are always atomic on a non SMP
machine. This is not guaranteed when multiple cores are present.

E.g.

Thread 1                      Thread 12
int count;                      count++;
count++ ;                       ---

Here count++ will always be done atomically on non SMP, but atomicity is not guaranteed when multiple cores
are present. To guarantee atomicity use atomic_t or sig_atomic_t.

CMIIW.

Regards,
Sandeep.
 

--
Regards,
Seshikanth