[lug] Tom Cargill's Go talk

[Rob Nagler]

Tom Christiansen writes:
> I agree with you, Rob, that proper management of shared data is something
> any experienced programmer should be plenty used to.

Uh oh, now what are we going to talk about?

> I was given to (mis?)understand that unprotected maps could corrupt not
> only data in a contended map, but also the program's whole execution state
> so it later crashes in various messy and mysterious ways.  That's a worse
> outcome than I'd've expected.  

It probably is that way now, because they're lazy or not ready for
prime time.  They should have an internal mutex for updating
datastructures like this.  It's no different than the Linux kernel
getting hit with multiple events.  The kernel itself is threadsafe,
but external calls are not, e.g. calls to printf, etc.

>     // TODO(rsc): Make sure map access in separate thread is safe.
>     func iterate(c chan<- KeyValue) {
> 	for k, v := range vars {
> 	    c <- KeyValue{k, v}
> 	}
> 	close(c)
>     }

Wow, this looks as syntax-rich as Perl.

> I'm probably just being slow again, but I don't see how maps are more
> troublesome for multithreaded programming in Go than any other data type.

int, double, char, etc. operations are atomic at the processor level
so they don't need mutexes.  Obviously anything you build on these
operations is not protected, but that's not a language issue.

> Because it's normally passed by reference, and programmers might forget?
> Or is it more than this?  

I think b/c it's a complex data structure, and can't be atomically
updated by a single machine instruction.

> Is read access also a problem, or just write access?  

I would think both would be a problem.  If you are in the middle of
updating the datastructure, you might be reading something
that is half-written.  That being said, cleverly designed write
operations might be possible, just like we do with certain file
systems.

> Why can it hose the program state?  

If they're doing pointer manipulations unatomically, that's going to
make a mess of things.

> Might it have to do with the implementation of the dynamically
> sized hash table?

:)

> Do the "incorrect synchronization" examples shown in
> http://golang.org/doc/go_mem.html#tmp_111 have bearing 
> on this map issue? (I'm thinking not.)

I think so.  They are being honest about optimizations: "compilers and
processors may reorder the reads and writes executed".  I have
experienced bugs in kernels where there's incorrect synchronization as
they describe, and it is *very* hard to debug.

> Me, I kinda like the idea of a Scheme and Python and C++ regimen
> with zero proprietary indoctrination, but I'm not a good little M$FT
> soldier.  (Not that I'm a great fan of C++, mind you.)

Oh, I don't think this is a Microsoft problem, or even a "we have to
teach them something they can use" problem.  I learned UCSD Pascal on
a P-machine, which at the time was not in use anywhere.  The system
was designed as a way of teaching people programming.  However, what
it did was teach me the wrong things about programming, and I've been
unlearning those things for several decades now.  Unfortunately, the
feedback loop for universities is self-fulfilling.  They churn out
people who understand how to solve simple problems with structured
languages, and those people get promoted and want people who
understand how to solve simple problems with structured languages.

Rob