Atomic operations and Thread safe code

bl************@ hotmail.com wrote:

consider this code :

int i; //gobal var

Thread1:
i=some value;

Thread2:
if (i==2) dosomething();
else dosomethingelse ();

I want to write it to be thread safe without using synchronization
objects.

my questions are:

1) is an assignment operation of an int atomic in c/c++?
if so will thaat code work?
No and no.
volatile int i;

int getI()
{ return i;//assignment is atomic so assignment to return
value will be atomic also
}

void setI(int somevalue)
{
i=somevalue;//assignment atomic
}

Thread1:
setI(somevalue) ;

Thread2:
if (getI()==2) dosomething();
else dosomethingelse ();
2) what operations in c are atomic?
are mailslots pipes etc operations atomic/threadsafe ?

Modifications of objects of type sig_atomic_t (C99) are atomic in C. As
for C++ ask in a C++ newgroup.

However simply using atomic objects doesn't garuntee synchronisation
and threads as well as thread safe code are outside the scope of
standard C. Generally, you'll have to use external libraries like
pthreads or make use of specific API functions of your underlying
operating system.

For further questions on this topic please try to confine your postings
to more relavent groups like comp.programmin g.threads etc.

bl************@ hotmail.com schrieb:

consider this code :

int i; //gobal var

Thread1:
i=some value;

Thread2:
if (i==2) dosomething();
else dosomethingelse ();

I want to write it to be thread safe without using synchronization
objects.

my questions are:

1) is an assignment operation of an int atomic in c/c++?
if so will thaat code work?

I can't speak for C++, but probably the situation is similar;
ask in comp.lang.c++ to be sure.
In standard C, there are no threads; the C99 standard speaks
only of atomic operations with respect to contraction of
floating expressions.
Ask in a newsgroup for your operating system for the respective
brand of threads etc.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

Michael Mair wrote:
.... snip ...

the C99 standard speaks only of atomic operations with
respect to contraction of floating expressions.

I may have misunderstood, but what about operations on objects of type
<i>sig_atomic_t </i>?

In article <11************ *********@z34g2 000cwc.googlegr oups.com>,
santosh <sa*********@gm ail.com> wrote:

Modification s of objects of type sig_atomic_t (C99) are atomic in C.

I do not have my C89 standard handy at the moment. My recollection
is that in C89, the atomicity promises on sig_atomic_t only
hold in signal handlers and only for volatile sig_atomic_t.
The types of operations that are atomic
are restricted, but I do not recall the details at the moment.

The OP wanted to use atomic operations without using a synchronization
object. In C89, the minimum is to use a signal handler -- but if one
is using multiple threads then [generally speaking] one might be using
multiple processes, so it is possible that there are multiple signal
handlers active at any one time, so signal handlers should not be
considered to be a stand-in for thread synchronization .

In short, to do anything -useful- with sig_atomic_t requires relying
on implementation-specific extensions... and if you have those then
you should probably use a implementation-specific synchronization
primitive rather than risking very subtle race conditions that you
did not happen to think of.
--
There are some ideas so wrong that only a very intelligent person
could believe in them. -- George Orwell

santosh schrieb:

Michael Mair wrote:
... snip ...

the C99 standard speaks only of atomic operations with
respect to contraction of floating expressions.

I may have misunderstood, but what about operations on objects of type
<i>sig_atomic_t </i>?

Hmmm, good point. In principle, you have an integer type that
is an atomic entity w.r.t. _access_, even if you have interrupts.
The only kind of operations that do not have undefined behaviour
is assignment of a value to an object of type volatile sig_atomic_t.
This is effectively useless for meaningful portable programs --
as is the whole standard conforming part of C signal handling.

I consider <signal.h> as a suggestion how signal handling should be
done so that porting does not become too hard.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

In article <e0**********@c anopus.cc.umani toba.ca>,
Walter Roberson <ro******@ibd.n rc-cnrc.gc.ca> wrote:

The OP wanted to use atomic operations without using a synchronization
object. In C89, the minimum is to use a signal handler -- but if one
is using multiple threads then [generally speaking] one might be using
multiple processes, so it is possible that there are multiple signal
handlers active at any one time, so signal handlers should not be
considered to be a stand-in for thread synchronization .

Sorry, that should have read "multiple processors", not "multiple
processes". Some threading libraries can only have one of the threads
executing at any one instant, but other threading libraries can
distribute to multiple processors, with all the race conditions that
that implies.
Hmmm, I remember a second ago that the last time around we had
the atomicity debate, someone posted a reference to a software-only
synchronization method. It wasn't clear to me from the papers
whether that applied on multiple processors.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton