Protected objects à la Ada

[xavier...@gmail.com]

Hello,
I'm a former Ada programmer (ada83 and ada95) and one of the most
important feature added by ada95 was the protected objects. I recall
in mind that in ada83 communication between threads was made through
Rendez-vous (kind of channels). Th protected object notion has been
added to avoid many deadlocks which can appear with the use of
channels...
Of course I could implement easily protected object-like types with
go, but I would like to know if this notion has been envisaged when
designing the go language?
best regards
Xavier

[Russ Cox]

---
http://golang.org/doc/go_programming_faq.html#What_operations_are_atomic_What_about_mutexes

We hope Go programming style will encourage people to try
higher-level techniques. In particular, consider structuring your
program so that only one goroutine at a time is ever responsible
for a particular piece of data.

http://golang.org/doc/go_lang_faq.html#atomic_maps

After long discussion it was decided that the typical use of maps
did not require safe access from multiple threads, and in those
cases where it did, the map was probably part of some larger data
structure or computation that was already synchronized.
Therefore requiring that all map operations grab a mutex would
slow down most programs and add safety to few.
---

I think the map situation applies to the case for "protected objects"
(aka Java synchronized) too. Making individual data structures
atomic is only useful when those data structures are the only thing
in the program. More commonly, higher level code combining them
wants to ensure invariants across data structures, in which case
the higher-level coordination makes lower-level mutexes redundant.

Russ

[Daniel Smith]

On Fri, May 28, 2010 at 12:38 PM, Russ Cox <r...@golang.org> wrote:

After long discussion it was decided that the typical use of maps
did not require safe access from multiple threads, and in those
cases where it did, the map was probably part of some larger data
structure or computation that was already synchronized.
Therefore requiring that all map operations grab a mutex would
slow down most programs and add safety to few.

I've been meaning to ask: I'm making the assumption that it's OK to have multiple concurrent readers of a map if no one will be writing to it. Is this a safe assumption? The documentation doesn't seem to say one way or the other.

--
Daniel Smith
http://www.schaumburggoclub.org/

[Rob 'Commander' Pike]

On May 28, 2010, at 10:53 AM, Daniel Smith wrote:

>
>
> On Fri, May 28, 2010 at 12:38 PM, Russ Cox <r...@golang.org> wrote:
> After long discussion it was decided that the typical use of maps
> did not require safe access from multiple threads, and in those
> cases where it did, the map was probably part of some larger data
> structure or computation that was already synchronized.
> Therefore requiring that all map operations grab a mutex would
> slow down most programs and add safety to few.
>
> I've been meaning to ask: I'm making the assumption that it's OK to have multiple concurrent readers of a map if no one will be writing to it. Is this a safe assumption?

Yes

-rob

[Xavier Mehaut]

thanks for the detailed answer Russ
what i see interesting in protected objects is the asynchronous
communication vs the synchronous one
regards
xavier

Envoyé de mon iPhone

[Russ Cox]

On Fri, May 28, 2010 at 11:18, Xavier Mehaut <xavier...@gmail.com> wrote:
> what i see interesting in protected objects  is the asynchronous
> communication vs the synchronous one

Can you elaborate? I haven't done any Ada programming,
so I searched the web and found these descriptions of
protected objects:
http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/node25.htm
http://en.wikibooks.org/wiki/Ada_Programming/Tasking#Protected_types
http://www.adaic.org/docs/95style/html/sec_6/6-1-1.html

and I don't see anything about asynchronous communication there.

Russ

[Xavier Mehaut]

shortly, your protected object implements several ways of
communicating between several threads ( some are producers others
consummers), entry points, procedures (read/write) and functions
(readonly). By using these means the producer can deliver its resource
without being blocked while the consumers try to consume resources( of
course they are blocked if the resource is not available)
Witg go we can mimic this behavior of course, but in ada it is native
(furthermote you can add on entries some guards or timers too)
by desynchronising thread communicatipn ( the paradigm) you avoid many
deadlock situations
regards
Envoyé de mon iPhone

[Russ Cox]

You can create an asynchronous (buffered) channel.

Russ