Atomicity block

[Alexi]

Many languages introduce structures/keywords for critical sections,
monitors and other similar stuff that does synchronisation, mutual
exclusion and etc. Is there anything similar for atomicity? I mean
some monitor-like construction that would tell compiler to generate
uninterraptable code that would have exclusive access to all addressed
memory and may be other resources. All asynchronous events may be
suspended until the end of such construct, that seems quite possible.
And waht about exclusive memory access? This might require some
support from OS/HW

If we are speaking in terms of some high-level language, can we build
atomicity using monitors and mutexes (ignoring async signals)? I mean
if one protects all the global variables using mutexes, puts monitor
on the method, will he get atomic routine?

[Les Cargill]

Post by Alexi
Many languages introduce structures/keywords for critical sections,
monitors and other similar stuff that does synchronisation, mutual
exclusion and etc. Is there anything similar for atomicity? ...

It's probably better to have an O/S ( and probably hardware ) support
these things, so that language/compiler implementation may remain
uncluttered by these issues.

Ada has keywords for atomicity, but Ada didn't do very well in the
marketplace. Shame, it's a nice system.
--
Les Cargill

[Nick Maclaren]

In article <04-02-***@comp.compilers>,
Les Cargill <***@worldnet.att.net> writes:
|> Alexi wrote:
|> >
|> > Many languages introduce structures/keywords for critical sections,
|> > monitors and other similar stuff that does synchronisation, mutual
|> > exclusion and etc. Is there anything similar for atomicity? ...
|>
|> It's probably better to have an O/S ( and probably hardware ) support
|> these things, so that language/compiler implementation may remain
|> uncluttered by these issues.

However it is handled (and even "language-based" implementations often
are just wrappers for operating system calls), the language needs to
at least define the atomicity semantics. Take, for example, a simple
operation like:

ATOMIC INTEGER count = 0;

ATOMIC count +:= 1;

The language has to specify whether this is atomic for explicit
threads, a thread plus an interrupt handler, or both. In languages
with exception support (overflow, in this case), it has to specify
what happens when it overflows while being updated by two threads.

It gets REALLY hairy when you have peculiar, complex, non-orthogonal
and ill-specified exception mechanisms. The 'solution' to leave the
behaviour undefined so as not to handicap the implementation is almost
always a disaster, because distinction is rarely made between
"undefined" meaning unspecified reasonable behaviour and "undefined"
meaning that all hell may be let loose.

|> Ada has keywords for atomicity, but Ada didn't do very well in the
|> marketplace. Shame, it's a nice system.

Better than most, certainly.

Regards,
Nick Maclaren.

[Ken Hagan]

Post by Les Cargill
Ada has keywords for atomicity, but Ada didn't do very well in the
marketplace. Shame, it's a nice system.

Perhaps someone should make Ada look like C. It can't be that
hard, since it is only syntax. (I'm thinking of a full compiler
like Cfront, though a pre-processor might be sufficient to get
people interested.)

(You know the sort of thing: curly braces, up-its-own-backside
declaration syntax, overload the angle brackets for generics.)

A "C-like syntax" certainly worked for Java (and C++ before it).
Of course, you'd have to give it a new name, such as Ada++, or
else you'd never be able to market it to the great unwashed.


(No smiley. It was borderline, but on balance I think this is a
serious suggestion.)

[Les Cargill]

Post by Ken Hagan

Post by Les Cargill
Ada has keywords for atomicity, but Ada didn't do very well in the
marketplace. Shame, it's a nice system.

Perhaps someone should make Ada look like C. It can't be that
hard, since it is only syntax. (I'm thinking of a full compiler
like Cfront, though a pre-processor might be sufficient to get
people interested.)
(You know the sort of thing: curly braces, up-its-own-backside
declaration syntax, overload the angle brackets for generics.)
A "C-like syntax" certainly worked for Java (and C++ before it).

In the sense that a bowl haricut worked for the Rolling Stones...

Post by Ken Hagan
Of course, you'd have to give it a new name, such as Ada++, or
else you'd never be able to market it to the great unwashed.
(No smiley. It was borderline, but on balance I think this is a
serious suggestion.)

I thnk there really ought to be a moratorium* on languages. I know,
horrors! but it's the Tower of Babel out there as it is...

*Nothing harsh, just a suggestion for the language breeders to
consider the birth control patch...
--
Les Cargill
[It's about 35 years too late. The last interestingly innovative
language was Simula in 1967, but that hasn't kept people from
inventing new ones. -John]

[Joachim Durchholz]

[The last interestingly innovative language was Simula in 1967, but
that hasn't kept people from inventing new ones. -John]

Not entirely true. I see two new developments that postdate Simula:

1. Various constructs for initiating and controlling parallelism. (Given
Dijstra's talent for the unexpected and that Dijkstra published papers
on the issue as late as 1968, I assume that there were new ideas after
1967 *g*. Unfortunately, the various search machines that I tried were
too busy to check for sure.)

2. Simula had no multiple inheritance. Since Simula was the initial OO
language, I don't think there was another one.

3. There have been lots of advances in the area of combining various
forms of polymorphism and static typing.

4. There is a lot of innovation in the area of *integrating* paradigms.
As an example, take a look at:

Peter van Roy, Seif Haridi: Concepts, Techniques, and Models of
Computer Programming

A draft is available on http://www.info.ucl.ac.be/people/PVR/book.html
(it will go away shortly).

Well, at least that's what would be interestingly innovative for *me* -
YMMV :-)

Regards,
Jo
--
Currently looking for a new job.

[Thad Smith]

Post by Alexi
If we are speaking in terms of some high-level language, can we build
atomicity using monitors and mutexes (ignoring async signals)? I mean
if one protects all the global variables using mutexes, puts monitor
on the method, will he get atomic routine?

It depends on what you mean by atomic. Mutexes can be used to prevent
inhibit access to any particular resource by a routine which utilizes
the mutex for that purpose. That is usually sufficient. That doesn't
apply to interrupt routines, though, which cannot wait on a mutex. If
you want to inhibit them, you need to disable the interrupt. If you
are running on a multiprocessor with each processor having access to a
common memory, even disabling interrupts doesn't work there. There
are usually bus locks for multiprocessing systems for this sort of
thing, but they are usually only implemented for very short sequences,
such as incrementing a memory location or test-and-set instruction.

Thad

[T.L. Harris]

Post by Alexi
Many languages introduce structures/keywords for critical sections,
monitors and other similar stuff that does synchronisation, mutual
exclusion and etc. Is there anything similar for atomicity? I mean
some monitor-like construction that would tell compiler to generate
uninterraptable code that would have exclusive access to all addressed
memory and may be other resources. All asynchronous events may be
suspended until the end of such construct, that seems quite possible.
And waht about exclusive memory access? This might require some
support from OS/HW

Keir Fraser and I had a paper along these lines at OOPSLA 2003. We
used a software transactional memory (STM) as the basis of the
implementation. The paper focussed on making atomic updates to data
structures held in shared memory, but we've had some thoughts about
how to extend it to deal with some forms of I/O.

There are links to our work at

http://www.cl.cam.ac.uk/netos/lock-free

Tim

[EventHelix.com]

I don't think any language supports primitives for atomicity. The
support for atomicity varies greatly amongst processors, so it seems
unlikely that a language primitive could address this.

Sandeep
--
http://www.EventHelix.com/EventStudio