Comment 5 for bug 727615

On Wed, Mar 2, 2011 at 11:12 PM, Roman Marynchak
<email address hidden>wrote:

> Regarding the real-life example, imagine a hash table which holds a

structure called 'relation' as a value, and a relation name as a key.
> The relation is something like '(A RELATED-TO B), and a name is a
> symbol. There are 10 rules, each of them running in its own thread,
> which are interested in this relation. Two of them can change it, other
> eight can only read it. All rules are launched every 1 second, they
> execute during 50ms and then sleep the rest time waiting for the next
> launch. In case hash-table is thread-safe, this stuff works perfectly,
> just because the maximum action delay upon a _final_ relation change is
> 1 second, which is not a problem (relation changes are allowed to
> overwrite one another without any action). But in case a table is not
> thread-safe, and a relation value becomes garbage, we are likely to end
> up in the debugger.
>

Just because it's possible to come up with a convoluted situation where
synchronized hash-tables would actually provide a useful guarantee assuming
very strict timing discipline, it doesn't mean that they'd be useful
generally. I maintain that in the real world the synchronization protocol
for a hash table is very often going to be a more complicated than just a
lock on the primitive operation. So the effect of synchronization by default
is:

- Give a false sense of security for users who don't really understand safe
concurrent programming.
- Performance loss for users who have to do their own synchronization
anyway.
- Performance loss for users who don't need any synchronization.

I think the only principled defaults are either "just don't corrupt the
whole image" or "detect unsafe concurrent accesses and signal an error".

--
Juho Snellman