I am on a MacBook Air Early 2014 and my current link speed is 144 Mbit/s according to Network Utility, but fast.com shows between 210 to 230 Mbps on each run.
Speedtest.net results are consistent as before at ~38 Mpbs, which is what I would expect from the routers around me.
User for >4 years. Absolutely love the nifty little tool. But I hated opening up a terminal each time I wanted to initiate a download.
For PopClip[1] users on Mac, I made a little YouTube-dl extension[2] which lets you initiate the download just by selecting the video URL (best when done from browser's address bar) and clicking a button. Been using it as my primary ytdl client for past 5 months now.
> It doesn't matter what value is returned by a read that overlaps a write. The algorithm is correct even if reading a number while it is changing from 9 to 10 obtains the value 2496.
There are two variables involved in the bakery algorithm[1] -- choosing[k] and number[k]:
- choosing[k] takes only the two values 0 & 1, hence reading/writing to it is atomic.
- number[k] is boundless, hence the question of inconsistency while reading it. Lamport shows (see Assertion 2's Proof in [1]) that given,
1. tL2 < tL3 (on process i), and
2. te < tw < tc (on process k),
(in the non-trivial case) tc can only occur before tL2 (tc < tL2) => tw < tL3, that is process i reads the current value of number[k]. See, no overlap! "The bakery algorithm is correct as long as reading a number returns the correct value if the number is not concurrently being written".
I think it is much easier to understand with the two-arrow formalism presented later in the article.
