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

[seshikanth varma <seshikanthvarma@xxxxxxxxx>]

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 <sandeep.lahane@xxxxxxxxx> wrote:

On Fri, May 8, 2009 at 1:49 PM, seshikanth varma <seshikanthvarma@xxxxxxxxx> 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 <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

>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 }, 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