Hey this is really awesome :) ... One more thing u want to understand is that we have several concurrency problems like producer-consumer, reader-writer etc. How do i test these things ? Modifying these programs using the above logic would be complex .... Thanks a lot for making me understand these things,
On Fri, May 8, 2009 at 2:06 PM, sandeep lahane <[email protected]>wrote: > > > > On Fri, May 8, 2009 at 1:49 PM, seshikanth varma < > [email protected]> wrote: > >> 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 >> > > >Else is there any way of simulating the non-automicity with single core > (Any wrappers to do this)? > > How about signals? If you just want to understand how atomicity violation > can happen etc then > a simple test case like following might be useful. You can modify the test > case to have threads etc. > Have a look at the values printed from signal handler they should be always > 0,0 or 1,1, the moment you > see 1,0/0,1 you have hit a race condition. > > > #include <signal.h> > #include <stdio.h> > > struct two_words { int a, b; } *memory; > > void > handler(int signum) > { > printf ("%d,%d\n", memory->a, memory->b); > alarm (1); > } > > int > main (void) > { > static struct two_words zeros = { 0, 0 }, ones = { 1, 1 }; > struct sigaction sa; > sa.sa_handler = handler; > sa.sa_flags = 0; > > sigaction(SIGALRM, &sa, NULL); > > memory = malloc(sizeof(struct two_words)); > memcpy(memory, &zeros, sizeof(struct two_words)); > alarm (1); > while (1) > { > memcpy(memory, &zeros, sizeof(struct two_words)); > memcpy(memory, &ones, sizeof(struct two_words)); > } > } > > Regards, > Sandeep. > > > -- Regards, Seshikanth
