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))) ]

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

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))) ]
>
>

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))) ]

*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)

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)
>
>
>

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))) ]