6 ms·
The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t. And because you’re in production
by JackFr 6y ago
The problem for novices is that a program that behaves correctly looks a lot like a correct program. Until one day it doesn’t.
And because you’re in production and getting random spurious failures, the panicked (but common) reaction is to wrap every shared resource in a synchronized block. Which makes an incorrect implementation worse but possibly correct.
- FpUser 6y agoIf the resource is shared and being accessed from many threads and is both written to and read from then it is the correct behavior to to lock it with the proper type of lock at access time. Depending on resource it might be possible to split it into few with more granular access. As for novices: they are called that for reason and supposed to be under supervision rather than allowed running wild.
- secondcoming 6y agoWhy is this being downvoted? It's the truth. HN needs to only allow downvotes that have an accompanying explanation comment.
- teslalang 6y agoAs with most other compromised social sites, no badthink allowed here and how dare you.
- FpUser 6y agoHN uses downvotes mostly to boo the people with opinions deviating from common party line. As for reasonable explanation - you're asking too much. Programming as many other things often are treated as the religion. No arguments, it just is.
- ubercow13 6y agoWhat's a better alternative to synchronizing access to shared resources?
- mrkeen 6y agoTreat it like GC and don't leave it up to the programmer.
- FpUser 6y agoAn make a programmer unable to achieve highest performance when needed. We leave in supposedly free world. If you want to be "protected" be my guest and use languages with GC. Plenty of those. For somebody who need the opposite and uses "unprotected" tools - leave them alone. You have no rights to decide how other people do their work unless they're under your direct control.
- ubercow13 6y agoDoes that involve using concurrency primatives that basically don't allow access to any shared mutable state?
- mrkeen 6y agoI'd say provide concurrency primitives to disallow direct access to shared mutable state. You still do the reads and the writes, but you let the system take and release locks for you. Let's say you wanted to turn a list into a bounded list of 4 elements. Race-condition insert: if (sz < 4) { list.insert(x); sz++; } Safe insert: atomically { if (sz < 4) { list.insert(x); sz++; } } So atomically organises the locking/unlocking/rollback for you such that a fifth element will not be inserted.
- ubercow13 6y agoAren't the semantics of this exactly the same as Java's synchronise? What error does it protect you against compared to synchronising on list? What happens if .insert() also uses atomically{} somehow?
- deleted 6y ago[deleted]
- formerly_proven 6y agoNovices don't build working concurrent systems of any kind with any toolkit, period. Concurrency is hard and thinking all the "concurrency problems" go away with some message passing is both ludicrous and dangerous. Fearless concurrency can only be attained through understanding, not by thinking all your problems went away because you're using a "cool approach".
- abhishekjha 6y agoSurprisingly this is what the akka framework promises : Message passing and immutability of objects.
- FpUser 6y agoSoftware usually has state (unless that state is completely kept and managed externally in a database for example). And the state mutates. Simple case example is a big array that has to be processed in place.
- mrkeen 6y agoIt's pretty easy to make the leap from individual SQL statements to SQL statements which are wrapped in a transaction.
- formerly_proven 6y agoExcellent example for making my point, since "just wrap it in a transaction" usually leads to concurrency bugs like the beloved lost update.
- mrkeen 6y agoThis is not something I'm familiar with. What's the beloved lost update and what transactions are you using that suffer from it?
- formerly_proven 6y ago