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 <[email protected]>wrote: > > > > On Fri, May 8, 2009 at 10:40 AM, Mulyadi Santosa < > [email protected]> wrote: > >> On Fri, May 8, 2009 at 11:46 AM, mukti jain <[email protected]> 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 [email protected] >> 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
