While the hardware part of the job is nicely done, I think there still remains the problem of how to convey the information to the users.

Once a toilet becomes free, everybody waiting will try to aquire the ressource (ie: do a costly walk to the bathroom).

There must already be some gaming theory or performance modelling result that solves this issue, though.

Just a simple idea would be to add a random delay for propagating the information to different users.

One of my friends built software to track use of the two washers and two dryers at our local dormcubator. It relied on students to report that they had started a cycle by email; so long as students did this then the website could tell you when the cycle ended because the machines had fairly consistent cycle times.

While he built a virtual queue into the website (type in your email address and we'll send you an email when the last load is done) it turns out that people are really bad at picking up their laundry right when the machine finishes...

All this reminds me of Paul Heckbert's ray tracer written on the back of his business card: http://www.cs.cmu.edu/~ph/src/minray/minray.card.c

I wonder if providing this kind of information to the public can lead to worse performance (commute time).

This reminds me of Braess's Paradox [1].

[1] https://en.wikipedia.org/wiki/Braess_paradox

I recommend the excellent book 'Traffic' - http://www.amazon.co.uk/Traffic-drive-what-says-about/dp/014... - it covers this pretty well.

That's exactly what a threading library abstraction aims to do. For example the Intel TBB (Threading Building Blocks).

On an Intel i5-2520M (4 threads [1]) it reported 5 usable worker threads.

As I see from others, the result reported by core-estimator is spot on N+1, where N is the number of virtual cores [2].

It might be a coincidence, but this is exactly the number of jobs one would give to make when compiling [3].

Knowing N helps to be efficient when spawning threads (avoiding swamping or starving cores).

[1] http://ark.intel.com/products/52229/ [2] as reported for example by /proc/cpuinfo on Linux [3] i.e. "make -j5"