How does the workaround I found in
http://tracker.bro.org/bro/ticket/980#comment:1 interact with
&synchronized? In the below case, can the last line undo the line before
it?
node-1> foo[0]$x += 42;
node-2> foo[0]$x += 42;
node-1> foo[0] = foo[0];
Alternatively, is there a better workaround or will that bug be fixed
soon?
I've been moving away from the &synchronized attribute for quite a while and moving toward manual, explicit data sharing through events. My experience with using it was like you're discovering, there are so many complicated edge cases that we don't even reasonably have a good mechanism of handing well.
At some point we may have better primitives for synchronizing data across nodes easily, but we don't have anything concrete in progress yet.
Just something to think about. 
.Seth
Ok. Can you point me to an example script that does explicit data
sharing?
The metrics framework in 2.1 does it. In 2.2 the intel framework and the sumstats framework does it (sumstats is the renamed and expanded metrics framework).
.Seth
Yes, the 3rd line can undo the 2nd. For more consistency we'd need to
have some explicit synchronization/locking across nodes, which we
(deliberately) don't do. &synchronized provides a best-effort
solution, but it's not great if you need strict semantics.
Robin
It is possible to get more consistency without locking if node-1 sends a
message like "foo[0] = foo[0]" (instead of the "foo[0] = <data>" that I
assume it does now) to all other nodes and they execute that locally.
This adds complexity that may not be worthwhile though.
Anyway, after the discussion of #981 on bro-dev, I realized that this
workaround is also generally incorrect. Maybe #980 and #981 should be
merged since they're caused by the same thing that I initially
misunderstood?
Ok. Can you point me to an example script that does explicit data
sharing?
The metrics framework in 2.1 does it. In 2.2 the intel framework and
the
sumstats framework does it (sumstats is the renamed and expanded metrics
framework).
Just to make sure I'm understanding this correctly, if the name of an
event (lets call it foo) matches the Cluster::worker2manager_events
pattern, then "event foo();" on a worker node will queue up the event
handlers for foo on both that node and on the manager. Is that right?