www.digitalmars.com         C & C++   DMDScript  

D - Proposed keyword: atomic

reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
I think that variables (at least fundamental types) should be able to be
declared with the storage class modifier 'atomic'.  Atomic variables
would make the guarantee that all operations on them would be atomic.

Frankly, I would like this modifier to also apply to instance variables
of classes, with the compiler using locks to protect access...but that
may make things too complex.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Oct 31 2001
next sibling parent Russell Borogove <kaleja estarcion.com> writes:
Russ Lewis wrote:

 
 I think that variables (at least fundamental types) should be able to be
 declared with the storage class modifier 'atomic'.  Atomic variables
 would make the guarantee that all operations on them would be atomic.


Yeah, this is a fair point -- the "synchronize" block is okay as far as 
it goes, but if it's used inconsistently, it's no good at all.


 Frankly, I would like this modifier to also apply to instance variables
 of classes, with the compiler using locks to protect access...but that
 may make things too complex.


Modulo access-protection loopholes, this would amount to having the 
compiler wrap every member function in a synchronize block, which 
seems easy enough to do. 

-RB
Oct 31 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
The reason I haven't implemented it is because there would be a significant
penalty for using it - for each atomic variable there'd have to be a mutex
allocated, and every access would have to be wrapped (by the compiler) in a
try-finally block. More than a handful of uses would produce considerable
(perhaps unintended) bloat.

It's still probably worth considering.

But as a workaround, you can declare a synchronized get() function to read
it, an a synchronized put() function to set it, and you'll have equivalent
functionality.

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BE03D7B.5EC6C03 deming-os.org...

 I think that variables (at least fundamental types) should be able to be
 declared with the storage class modifier 'atomic'.  Atomic variables
 would make the guarantee that all operations on them would be atomic.

 Frankly, I would like this modifier to also apply to instance variables
 of classes, with the compiler using locks to protect access...but that
 may make things too complex.

 --
 The Villagers are Online! villagersonline.com

 .[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
 .[ (a version.of(English).(precise.more)) is(possible) ]
 ?[ you want.to(help(develop(it))) ]
Oct 31 2001
parent reply Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
How about atomic on fundamental types?  That doesn't require a mutex...and it
would be an invaluable feature for use multithreaded programmers.

Sample code:

int state;
switch(state)
{
   case INACTIVE: break;

   case ACTIVE:
      grabLock();
      doStuff();
      releaseLock();
};

If I can't declare state to be an atomic variable, then I must grab the lock
EVERY time...even just to check the state and find that it's empty :(

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Nov 01 2001
parent reply "Richard Krehbiel" <rich kastle.com> writes:
*Some* operations on *some* data types can be guaranteed by *some* machines
to be "atomic", for certain definitions of "atomic", in the presence of
certain other qualifications...  Basically, it's trickier than that.  You
just can't be sure you can offer atomicity, even on only the fundamental
data types, without mutex protection.

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:3BE17755.E51D13F6 deming-os.org...

 How about atomic on fundamental types?  That doesn't require a mutex...and


it

 would be an invaluable feature for use multithreaded programmers.


--
Richard Krehbiel, Arlington, VA, USA
rich kastle.com (work) or krehbiel3 home.com (personal)
Nov 01 2001
next sibling parent "Walter" <walter digitalmars.com> writes:
You're right. On the x86 machines, for example, atomicity only works for 32
bit or less sized values, and even then I think they have to be 32 bit
aligned to be atomic. doubles, 64 bit longs, and long doubles are not
atomic, which can lead to disastrous results in code that depends on
atomicity.

"Richard Krehbiel" <rich kastle.com> wrote in message
news:9rru2a$1iu5$1 digitaldaemon.com...

 *Some* operations on *some* data types can be guaranteed by *some*


machines

 to be "atomic", for certain definitions of "atomic", in the presence of
 certain other qualifications...  Basically, it's trickier than that.  You
 just can't be sure you can offer atomicity, even on only the fundamental
 data types, without mutex protection.

 "Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
 news:3BE17755.E51D13F6 deming-os.org...

 How about atomic on fundamental types?  That doesn't require a




mutex...and

 it

 would be an invaluable feature for use multithreaded programmers.


 --
 Richard Krehbiel, Arlington, VA, USA
 rich kastle.com (work) or krehbiel3 home.com (personal)
Nov 01 2001
prev sibling parent Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:
Right.  Sorry, didn't mean to imply that all would be possible in all
environments.  Basically, my assumption was that compilers would have the option
of reporting "atomic not supported for this type in this architecture."  For
operations not supported on the architecture, the compiler issues similar
compile-time errors: "atomic ++ not supported for 'unsigned long' on this
architecture".

Obviously, with something like atomicity, you can't assume total portability of
all code.  But you can say that the code is portable (and compiler supported) on
architectures that allow it.  For those that don't, your compiler has the option
of emulation (with implicit mutexes) or of simply bailing out.

My philosophy is that D should, at the compiler level, support major features
(particularly performance enhancements like atomic operatoins) even if not all
compilers will be able to implement them.  IMHO, one of the great downfalls of C
was to only support the lowest common denominator...thus, major features (like
atomic operations, network support, threads) are all relegated to a variety of
conflicting and confusing libraries.

Russ

Richard Krehbiel wrote:


 *Some* operations on *some* data types can be guaranteed by *some* machines
 to be "atomic", for certain definitions of "atomic", in the presence of
 certain other qualifications...  Basically, it's trickier than that.  You
 just can't be sure you can offer atomicity, even on only the fundamental
 data types, without mutex protection.


--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]
Nov 01 2001