On Fri, May 8, 2009 at 1:49 PM, seshikanth varma <seshikanthvarma@xxxxxxxxx> wrote:
>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.
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 asoption 1: non SMPoption 2: SMPby 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:
> I suppose race is generated with LOOPCONSTANT = 100000,Uhm, could it be because it's "int"? integer, AFAIK, at least in x86
> 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.
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.
