The Old Man and His Smartphone, Episode V

So after many years of bragging about my wristwatch's exemplary battery lifetime (years, I tell you, years!!!), I find myself a member of that very non-exclusive group that worries about battery lifetime.  But I have been pleasantly surprised to find that my smartphone's battery lasts quite a bit longer than I would have expected, in fact, it is not unusual for the battery to last through two or three days of normal usage.  And while that isn't years, it isn't at all bad.

That is, battery lifetime isn't at all bad as long as I have location services (AKA GPS) turned off.

With GPS on, the smartphone might or might not make it through the day. Which is a bit ironic given that GPS was the main reason that I knew I would eventually be getting a smartphone.  And the smartphone isn't all that happy about my current policy of keeping the GPS off unless I am actively using it.  The camera in particular keeps whining about how it could tag photos with their locations if only I would turn the GPS on.  However, I have grown used to this sort of thing, courtesy of my television constantly begging me to connect it to Internet.  Besides, if my smartphone were sincerely concerned about tagging my photos with their locations, it could always make use of the good and sufficient location data provided by the cell towers that I happen to know that it is in intimate contact with!

GPS aside, I am reasonably happy with my smartphone's current battery lifetime.  Nevertheless, long experience with other battery-powered devices leads me to believe that it will undergo the usual long slow decay over time.  But right now, it is much better than I would have expected, and way better than any of my laptops.

Then again, I am not (yet) in the habit of running rcutorture on my smartphone...

The Old Man and His Smartphone, Episode IV

I took my first GPS-enabled road trip today in order to meet a colleague for lunch.  It was only about an hour drive each way, but that was nevertheless sufficient to highlight one big advantage of GPS as well as to sound a couple of cautionary notes.

The big advantage didn't seem particularly advantageous at first.  The phone had announced that I should turn left at Center Street, but then inexplicably changed its mind, instead asking me to instead turn left on a road with a multi-syllabic vaguely Germanic name.  On the return trip, I learned that I had actually missed the left turn onto Center Street courtesy of that road's name changing to Wyers Road at the crossing.  So I saw a sign for Wyers Road and sensibly (or so I thought) elected not to turn left at that point.  The phone seamlessly autocorrected, in fact so seamlessly that I was completely unaware that I had missed the turn.

The first cautionary note involved the phone very quickly changing its mind on which way I should go.  It initially wanted me to go straight ahead for the better part of a mile, but then quickly and abruptly asked me to instead take a hard right-hand turn.  In my youth, this abrupt change might have terminally annoyed me, but one does (occasionally) learn patience with advancing age.

That and the fact that following its initial advice to go straight ahead would have taken me over a ditch, through a fence, and across a pasture.

The second cautionary note was due to the Fall colors here in Upstate New York, which caused me to let the impatient people behind me pass, rather than following my usual practice of taking the presence of tailgaters as a hint to pick up the pace.  I therefore took a right onto a side road, intending to turn around in one of the conveniently located driveways so that I could continue enjoying the Fall colors as I made my leisurely way up the highway.  But my smartphone instead suggested driving ahead for a short way to take advantage of a loop in the road.  I figured it knew more about the local geography than I did, so I naively followed its suggestion.

My first inkling of my naivete appeared when my smartphone asked me to take a right turn onto a one-lane gravel road.  I was a bit skeptical, but the gravel road appeared to have been recently graveled and also appeared to be well-maintained, so why not?  A few hundred yards in, the ruts became a bit deeper than my compact rental car would have preferred, but it is easy to position each pair of wheels on opposite sides of the too-deep rut and continue onwards.

But then I came to the stream crossing the road.

The stream covered perhaps 15 or 20 feet of the road, but on the other hand, it appeared to be fairly shallow in most places, which suggested that crossing it (as my smartphone was suggesting) might be feasible.  Except that there were a few potholes of indeterminate depth filled with swiftly swirling water, with no clear way to avoid them.  Plus the water had eroded the road surface a foot or two below its level elsewhere, which suggested that attempting to drive into the stream might leave my rental car high-centered on the newly crafted bank, leaving my poor car stuck with its nose down in the water and its rear wheels spinning helplessly in the air.

Fortunately, rental cars do have a reverse gear, but unfortunately my body is less happy than it might once have been to maintain the bent-around posture required to look out the rear window while driving backwards several hundred yards down a windy gravel road.  Fortunately, like many late-model cars, this one has a rear-view camera that automatically activates when the car is put into the reverse gear, but unfortunately I was unable to convince myself that driving several hundred yards backwards down a narrow and windy gravel road running through a forest was a particularly good beginner's use of this new-age driving technique.  (So maybe I should take the hint and practice driving backwards using the video in a parking lot?  Or maybe not...)

Which led to the next option, that of turning the car around on a rutted one-lane gravel road.  Fortunately the car is a compact, so this turned out to be just barely possible, and even more fortunately there were no other cars on the road waiting for me to complete my multipoint-star turn-around manuever.  (Some of my acquaintances will no doubt point out that had I been driving a large pickup, crossing the stream would have been a trivial event unworthy of any notice.  This might be true, but I was in fact driving a compact.)

But all is well that ends well.  After a few strident but easily ignored protests, my phone forgave my inexplicable deviation from its carefully planned and well-crafted route and deigned to guide me the rest of the way to my destination.

And, yes, it even kept me on paved roads.

The Old Man and His Smartphone, Episode III

I still haven't installed many apps, but I have already come across lookalike apps that offer interesting services that are less pertinent to my current mode of existence than the apps I was actually looking for.  So perhaps app spam will become as much an issue as plain old email spam.

I also took my first-ever selfie, thus learning that using the camera on the same side of the smartphone as the screen gets you a mirror-imaged photograph.  I left the selfie that way on my obligatory Facebook post for purposes of historical accuracy and as a cautionary tale, but it turns out to be quite easy to flip photos (both horizonally and vertically) from the Android Gallery app. It is also possible to change brightness and contrast, add captions, add simple graphics, scrawl over the photo in various colors, adjust perspective, and so on.  An application popped up and offered much much much more (QR code scanning! OCR! Other stuff I didn't bother reading!), but only if I would agree to the license.  Which I might do some time in the future.

I have not yet worked out how I will carry the smartphone long term.  For the moment, it rests in the classic nerd position in my shirt pocket (truth in advertising!!!).

My wife was not all that impressed with the smartphone, which is not too surprising given that grade-school students commonly have them.  She did note that if someone broke into it, they could be taking pictures of her without her knowledge.  I quickly overcame that potential threat by turning the smartphone the other side up, so that any unauthorized photography would be confined to the inside of my shirt pocket.  :-)

The Old Man and His Smartphone, Episode II

At some point in the setup process, it was necessary to disable wifi.  And I of course forgot to re-enable it.  A number of apps insisted on downloading new versions.  Eventually I realized my mistake, and re-enabled wifi, but am still wondering just how severe a case of sticker shock I am in for at the end of the month.

Except that when I re-enabled wifi, I did so in my hotel room.  During the last day of my stay at that hotel.  So I just now re-enabled it again on the shuttle.  I can clearly see that I have many re-enablings of wifi in my future, apparently one per hotspot that I visit.  :-)

Some refinement of notifications is still required.  Some applications notify me, but upon opening the corresponding app, there is no indication of any reason for notification.  I have summarily disabled notifications for some of these, and will perhaps learn the hard way why this was a bad idea.  Another issue is that some applications have multiple devices on which they can notify me.  It would be really nice if they stuck to the device I was actively using at the time rather than hitting them all, but perhaps that is too much to ask for in this hyperconnected world.

My new smartphone's virtual keyboard represents a definite improvement over the multipress nature of text messaging on my old flip phone, but it does not hold a candle to a full-sized keyboard.  However, even this old man must confess that it is much faster to respond to the smartphone than to the laptop if both start in their respective sleeping states.  There is probably an optimal strategy in there somewhere!  :-)

The Old Man and His Smartphone, Episode I

I have long known that I would sooner or later be getting a smartphone, and this past Tuesday it finally happened.  So, yes, at long last I am GPS-enabled, and much else besides, a little of which I actually know how to use.

It took quite a bit of assistance to get things all wired together, so a big "Thank You" to my fellow bootcamp members!  I quickly learned that simply telling applications that they can't access anything is self-defeating, though one particular application reacted by simply not letting go of the screen.  Thankfully someone was on hand to tell me about the button in the lower right, and how to terminate an offending application by sweeping up on it. And I then quickly learned that pressing an app button spawns a new instance of that app, whether or not an instance was already running.  I quickly terminated a surprising number of duplicate app instances that I had spawned over the prior day or so.

Someone also took pity on me and showed me how to silence alerts from attention-seeking apps, with one notable instance being an app that liked to let me know when spam arrived for each instance of spam.

But having a portable GPS receiver has proven handy a couple of times already, so I can already see how these things could become quite addictive.  Yes, I resisted for a great many years, but my smartphone-free days are now officially over.  :-)

Announcement: Change of Venue

This week of September 30th marks my last week at IBM, and I couldn't be more excited to be moving on to the next phase of my career by joining a great team at Facebook! Yes, yes, I am bringing with me my maintainership of both Linux-kernel RCU and the Linux-kernel memory model, my editing of "Is Parallel Programming Hard, And, If So, What Can You Do About It?", and other similar items, just in case you were wondering. ;-)

Of course, it is only appropriate for me to express my gratitude and appreciation for the many wonderful colleagues at IBM, before that at Sequent, and more recently at Red Hat. Together with others in the various communities, we in our own modest way have changed the world several times over. It was a great honor and privilege to have worked with you, and I expect and hope that our path will cross again. For those in the Linux-kernel and C/C++ standards communities, our paths will continue to run quite closely, and I look forward to continued productive and enjoyable collaborations.

I also have every reason to believe that IBM will continue to be a valuable and essential part of the computing industry as it continues through its second century, especially given the recent addition of Red Hat to the IBM family.

But all that aside, I am eagerly looking forward to starting Facebook bootcamp next week. Which is said to involve one of those newfangled smartphones. ;-)
elephant, penguin

Confessions of a Recovering Proprietary Programmer, Part XVI

I build quite a few Linux kernels, mostly in support of my deep and abiding rcutorture habit. These builds can take some time, even on modern laptops, but they are nevertheless amazingly fast compared to the build times of the much smaller projects I worked on in decades past. Additionally, build times are way down in the noise when I am doing multi-hour rcutorture runs. So much so that I don't bother with cut-down kernel configurations, especially given that cut-down configurations are an excellent way to fail to spot subtle RCU API problems.

Still, faster builds do have their advantages, especially when doing a series of short tests, such as when chasing down that rarest of creatures, an RCU bug that reproduces reliably within a few minutes of boot. Which is exactly what I was doing yesterday. And during that time, a five-minute kernel build time was much more annoying than it normally would be.

But that is why we have ccache, a tool that is considerably more attractive than it was back when my laptop's mass storage weighed in at “only” a few tens of gigabytes. With a bit of help from here, here, and the ccache man page, I got ccache up and running, and somewhat later got it actually making kernel builds go faster. Sometimes considerably more than an order of magnitude faster!

But I do get spoiled really quickly.

You see, the first ccache build goes no faster than a normal build because the cache is initially empty. And yes, a five, six, or even seven-minute build was just fine a couple of days ago: After all, there is always some small task that needs to be done. But having just witnessed builds completing in way less than one minute, even a five-minute wait now seemed horribly slow. And a five-minute build is what I get the first time I run a given rcutorture scenario. Or after I modify an rcutorture scenario. Or if I specify unusual arguments to rcutorture's --kconfig command-line option. Or if I modify a heavily used include file. Or when I configured ccache's cache size too small.

Nevertheless, I most definitely should have installed ccache a very long time ago! :-)

Parallel Programming: March 2018 deferred-processing query

TL;DR: Do you know of additional publicly visible production uses of sequnce locking, hazard pointers, or RCU not already called out in the remainder of this blog post?

I am updating the deferred-processing chapter of “Is Parallel Programming Hard, And, If So, What Can You Do About It?” and would like to include a list of publicly visible production uses of sequence locking, hazard pointers, and RCU. I suppose I could also include reference counting, but given that it was well known before I was born, I expect that its list would be way too long to be useful!

The only production use of sequence locking that I am aware of is within the Linux kernel, but I would be surprised if it is not rather widely used. Can you tell me of more publicly visible production sequence-locking uses?

Hazard pointers is used within MongoDB (v3.0 and later) and within Facebook's Folly library, which is used in production at Facebook and perhaps elsewhere as well. It is also implemented by several libraries called out on its Wikipedia page (Concurrent Building Blocks, Concurrency Kit, Atomic Ptr Plus, and libcds). Hazard pointers is also sometimes called “safe memory reclamation” (SMR). Any other production hazard-pointers uses?

RCU is used within the Linux kernel, the FreeBSD kernel, the OpenBSD kernel, Linux Trace Toolkit Next Generation (LTTng), QEMU, Knot DNS, Netsniff-ng, Sheepdog, GlusterFS, and gdnsd. It is also implemented by several libraries, including Userspace RCU, Concurrency Kit, Facebook's Folly library, and libcds. RCU is also called “epochs” (from Keir Fraser), “generations” (from Tornado/K42), “passive serialization” (from IBM zVM), and probably other things as well. Any other production RCU uses?

So what do I mean by “publicly visible”? Open-source projects should qualify, as should scholarly publications regarding proprietary projects. Similarly, “production use” means use for getting some job done, as opposed to research, prototyping, or benchmarking. Not that there is necessarily anything wrong with research, prototyping, or benchmarking, but we are looking for things a little bit further along the hype cycle. ;-)

Article review: "The Hard Truth About Innovative Cultures"

There has been much ink spilled about innovation over the past decades, but this article from Harvard Business Review is the first one that really rings true with my experiences. The main point of this article is that much prior writing has focused on the fun aspects of innovation, and points out some additional hard work that is absolutely required for meaningful innovation. The authors put forth five maxims, each of which is discussed below.

Tolerance for failure but no tolerance for incompetence. This maxim is the one that rings most true with me: Innovation's progress is often measured in errors per hour, but the errors have to be productive errors that either eliminate classes of potential solutions from consideration or that better approximate a useful solution. And in my experience, extreme competence is required to make the right mistakes, that is, the mistakes that will generate the experience required to eventually arrive at a workable solution.

However, this maxim is also the one that I am most uncomfortable with. The discomfort stems from the choice of the word “incompetence”. After all, what is incompetence? The old apprentice/journeyman/master trichotomy is a useful guide. An apprentice is expected to do useful work if overseen by a journeyman or master. A journeyman is expected to be capable of carrying out a wide range of tasks without guidance. A master is expected to be able to extend the state of the art as needed to complete the task at hand. Clearly, there is a wide gulf between the definition of “incompetence” appropriate for an apprentice on the one hand and a master on the other. The level of competence required for this sort of work is not a function of education, certifications, or seniority, but instead requires a wide range of deep skills and experience combined with a willingness to learn things the hard way, along with a tolerance for the confusion and disorder that usually accompanies innovation. In short, successful innovation requires the team have a fair complement of masters. Yet it makes absolutely no sense to label as “incompetent” an accomplished journeyman, even if said journeyman is a bit uncreative and disorder-intolerant.

All that aside, “Tolerance for failure but no tolerance for non-mastery” doesn't exactly roll off the tongue, and besides which, large projects would have ample room for apprentices and journeymen, for example, our hypothetical accomplished but disorder-intolerant journeyman might be an excellent source of feedback. And in fact, master-only teams tend to be quite small [PDF, paywalled, sorry!]. I therefore have no suggestions for improvement. And wording quibbles aside, this maxim seems to me to be the most important of the five by far.

Willingness to experiment but highly disciplined. Although it is true that sometimes the only way forward is a random walk, it is still critically important to keep careful records of the experiments and their outcomes. It is often the case that last week's complete and utter failure turns out to contain the seeds of this week's step towards success, and sometimes patterns within a depressing morass of failures point the way to eventual success. The article also makes the excellent point that stress-testing ideas early on avoids over-investing in the inevitable blind alleys.

Psychologically safe but brutally candid. We all fall in love with our ideas, and therefore we all need the occasional round of “frank and open” feedback. If nothing else, we should design our experiments (or, in software, our validation suites) to provide that feedback.

Collaboration but with individual accountability. Innovation often requires that individuals and teams buck the common wisdom, but common wisdom often carries the day. Therefore, those individuals and teams must remain open to feedback, and accountability is one good way to help them seek out feedback and take that feedback seriously.

Flat but strong leadership. Most of my innovation has been carried out by very small teams, so this maxim has not been an issue for me. But people wishing to create large but highly innovative teams would do well to read this part of the article very carefully.

In short, this is a great article, and to the best of my knowledge the first one presenting both the fun and hard-work sides of the process of innovation. Highly recommended!

Parallel Programming: December 2018 Update

This weekend features a new release of Is Parallel Programming Hard, And, If So, What Can You Do About It?.

This release features Makefile-automated running of litmus tests (both with herd and litmus tools), catch-ups with recent Linux-kernel changes, a great many consistent-style changes (including a new style-guide appendix), improved code cross-referencing, and a great many proofreading changes, all courtesy of Akira Yokosawa. SeongJae Park, Imre Palik, Junchang Wang, and Nicholas Krause also contributed much-appreciated improvements and fixes. This release also features numerous epigraphs, modernization of sample code, many random updates, and larger updates to the memory-ordering chapter, with much help from my LKMM partners in crime, whose names are now enshrined in the LKMM section of the Linux-kernel MAINTAINERS file.

As always, git:// will be updated in real time.

Oh, and the first edition is now available on Amazon in English as well as Chinese. I have no idea how this came about, but there it is!