HenryR

8 ms·

31.
Why does Paxos have learners?(the-paper-trail.org)
1 points by HenryR 10y ago|0 comments
32.
by HenryR 10y ago
That's precisely the point: if threads never block or yield the CPU, you can guarantee system-wide progress. If you have an algorithm which might deadlock, 'progress' isn't really well defined.
33.
by HenryR 10y ago
The whole point of a non-blocking algorithm is system-wide forward progress. Yes, this is much harder to do if a thread can suspend for an unbounded amount of time, but that's kind of the point of the article: being in the kernel allow
34.
Distributed systems Slack channel(dist-sys-slack.herokuapp.com)
2 points by HenryR 11y ago|0 comments
35.
by HenryR 12y ago
Here's one paper on the intersection of Byzantine fault tolerance, altruiusm and rational behaviour from UT Austin: https://www.cs.utexas.edu/lasr/download.php?uid=63
36.
The CAP Theorem FAQ(henryr.github.io)
111 points by HenryR 13y ago|24 comments
37.
by HenryR 14y ago
I think it's rather clear that he's talking about high availability in the CAP sense, which is precisely the kind of availability FoundationDB (rightly) doesn't claim to achieve ( http://foundationdb.com/#CAP ). BTW, the images are failing
38.
On some subtleties of Paxos(the-paper-trail.org)
1 points by HenryR 14y ago|0 comments
39.
The FLP theorem and the CAP theorem aren't the same thing(the-paper-trail.org)
1 points by HenryR 15y ago|0 comments
40.
A little light recruiting (or why you should really consider Cloudera)(the-paper-trail.org)
1 points by HenryR 15y ago|0 comments
41.
by HenryR 15y ago
You're right, it doesn't really. When I started building this list it was more carefully given over to graduate-level courses. It evolved into a bit of a repository of courses that aligned with my interests and thought were good.
42.
by HenryR 15y ago
You're mixing up 'premature optimisation' and 'unnecessary optimisation'. The first is making code faster that isn't the bottleneck, or dominating performance factor. The second is making something faster than it needs to be. Profiling help
43.
by HenryR 15y ago
That was the introductory blog post to which I referred - note the similar discussion in the comments.
44.
by HenryR 15y ago
Extremely familiar - see my articles at http://the-paper-trail.org/blog/?p=173 and http://the-paper-trail.org/blog/?p=190 for some tutorials I wrote on the subject. You're correct that failure detection and consensus are very deeply rel
45.
by HenryR 15y ago
It's not clear to me how, or if, failure detection is to be integrated with Doozer. Keith has said on the thread accompanying the announcement blog post that Doozer doesn't have the 'baggage' of sessions (which are used in ZooKeeper to mana
46.
by HenryR 15y ago
I think your definitions are good, although thread-centric - to be really precise you have to talk a bit about 'steps' in the operational semantics of the program, but it's not helpful usually to do so.
47.
by HenryR 15y ago
Right, but if you make assumptions about the scheduler, you are tied to that scheduler's implementation, which introduces a significant coupling between OS implementation and language runtime that doesn't win you much and commits you to an
48.
by HenryR 15y ago
As you say, from the perspective of the program any scheduling interleaving is possible. The OS can substitute a new scheduling algorithm any time it likes. Otherwise we could know that the possible set of executions is much smaller than
49.
by HenryR 15y ago
These are tricky waters, but here's what I see as the difference: Two separate threads that can run completely independently without any synchronisation are concurrent because it doesn't matter what order you run them in. Therefore there ar
50.
by HenryR 15y ago
Multiple threads of control aren't necessarily parallelisable. Consider a language runtime for which every thread takes the same global lock on the interpreter, and therefore prevents two threads running 'simultaneously'. You have concurren
51.
by HenryR 16y ago
Is Stevens vol. 2 in the public domain now? If not, that's pretty poor form, linking to a scanned pdf of the book.
52.
by HenryR 16y ago
Nowhere does this article provide a definition for big-O notation. Also some important details seem to be missed - in particular the fact that O(f(n)) describes an asymptotic _upper bound_ on f(n). For example, searching on an unsorted arra
53.
by HenryR 16y ago
A message queue is shared state. It may be more convenient shared state, and since it only needs to be got right once it might be more bulletproof shared state, but you have multiple threads that are serialising on access to a queue no matt
54.
by HenryR 16y ago
We have a copy at the office. It's fantastic at first glance - beautifully produced, well laid out, clearly written and sensibly organised.
55.
by HenryR 16y ago
Assuming of course that each connection is bidirectional, and if you are modelling the network like a graph then you may not have bidirectional links in order to capture some asymmetric edge weighting for routing purposes :)
56.
by HenryR 16y ago
The system may be unable to give you a consistent response, no matter who you ask. It really depends on how you build your protocol. Let's imagine a system where you want to be 100% available for reads, for any number of failures less than
57.
by HenryR 16y ago
"A curious inconsistency." I don't agree - availability is a totally meaningless property if you are allowed to occasionally return "no, I won't process your request". Such a response communicates nothing about the state of the atomic objec
58.
by HenryR 16y ago
"The reason failures are hard to detect in asynchronous networks is that permissible message transit times are unbounded; ie they refuse to acknowledge the presence of any partition. If you acknowledge the possibility of partitions, then yo
59.
by HenryR 16y ago
No, arbitrarily many doesn't automatically mean a huge amount :) This definition covers permanent partitions, but also encompasses temporary partitions which are effectively one dropped message or more. There exist protocols which will be b
60.
by HenryR 16y ago
No, it does mean always available - honestly :) If there is some time period during which requests are not responded to within a time bound, the system is not available then, and further is not a 'highly' or 100% available system. That is

More ›