I don’t know about you, but every time I have to program with threads and shared resources, I want to remove my face incrementally with a salad fork. Locks, mutexes, the synchronized keyword; all of these things can strike fear into the heart of a green developer. Most seasoned developers just fall into a rut of depression when …
Another alternative is Erlang
In "Programming Erlang", Joe Armstrong says "There are various solutions to this (transactional memory is probably the best), but these are at best kludges. At their worst, they are the stuf f of nightmares." He argues that the old imperative programming techniques that have served fast single-threaded machines so well need replacing with his Erlang "copy-everything" multi-mini-threaded approach.
Tim Bray of XML fame is running an interesting project called "Wide Finder" at http://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Finder to look at which multi-threaded approaches seem to work best at solving a simple problem. But none of the approaches in his list is yet using a Transactional Memory approach.
Here's one of the big brains behind Sun's HyTM: http://research.sun.com/scalable/moir.html and some background about his work at Sun: http://research.sun.com/minds/2007-1218/
It all looks fascinating - let's hope it works and we can enjoy more beer time.
Any details about performance
All this looks very good, are there any benchmark with numbers?
The fundamental question is: do I have to migrate ( ie: rewrite all the code ) my application for a ( not yet available ) 2GHz Rock aka SPARC-Solaris platform in the hope of increased perf, or is an eventual recompilation for ( readily available) 5Ghz Power6 the biggest gain?
At least what about memory access? At school I was taught to think in the "P-RAM" model, where memory access is infinetely scalable.
In practice I doubt the 16 cores of the Rock will have a fully concurrential access to the main memory.. There is always a bus...
POSIX Threading is bliss
How can you not enjoy POSIX thread programming. It is the last great frontier, with these days of dumbing down where you get a large slow cpu and memory hog of a program from poorly trained developers using bloatware tool kits.
These days anyone thinks they can program, hence the security holes and BSOD
Wash your mouth out with soap.
The language detracts from the message. Do you normally swear at people you've just met?
(Maybe you do).
@AC, I'm pretty sure you won't need to recompile your code to get a benefit from TM on Rock. I think it basically tries optimistic locking on syncronized sections, then rolls back the transaction if it hits a conflict. So the exact same syncronized code runs, but in an optimistic rather than pessimistic fashion.
You can try it out with the Adaptive Transactional Memory Test Platform (ATMTP) - details here: http://research.sun.com/scalable/pubs/
re: "there is always a bus."
The whole point of ROCK (and Niagara for that matter) is that memory is slow and getting slower in relation to CPU's. To say that Rock will be starved is nonsense. The faster single threaded CPU's (read Power6) are the ones that are starved for memory. The point of Rock is that when it is waiting for a bit of memory, it can still get work done, while other CPU's, such as Power, are just sitting there.
Content v. profanity
Good article, interesting choice of language the editors let through.
With enough articles like this, work's content filter may eventually put El Reg into the same category as some *ahem* other web sites and I'll need to seek justification to have it unblocked. Sterling examples of language like this isn't going to help argue my case if that eventuality happens.
Can't handle multithreading but call yourself a programmer?
Just because you know the language doesn't make you a programmer. If you can't handle simple stuff like multi threading or thread-synchronization, you surely won't handle the real design difficulties...
I do agree that any technological advance to help with thread-synchronization would be fine of course, an easier path is always nicer ;)
This looks to me like we are just trading one set of complexity and bugs for another set of complexity and bugs.
What is the difference betwen "synchronised" and "atomic" really.
Synchroised makes you wait for another thread to finish before you execute the code, atomic dives in there starts processing and aborts when it encounters another thread doing the same thing.
It may improve performance but I dont see how it makes anything simpler.
As for 10 times performance increase on Berkely DB locking.
Berkley is not exactly the most advanced piece of software out there!
I think SUN or on yet another hiding to nothing here, all the major software providers are striving for a code base which works on all the major platforms (hence the popularity of the Java). Oracle , SAP etc will need a pretty good reason to code a "rock chip only" version of thier software and I dont think Sun has a compeling enough case.
After all you can just tell your customers to buy a Power5 based server if they need a performance boost.
should only need 1 memory manger and just include in all your programs, or download 1
for a hard read this guy certainly made it enjoyable! thanks you made me laugh, and for a monday morning, trust me you did well!
Get a better thread library
(available for Lunix too via http://swtch.com)
No George Carlin
An interesting topic, and the in your face tone is fine.
But... the swearing takes away from it.
Seriously, do yourself a favour, keep the imaginative cursing and loose the humdrum expletives.
Interesting approach, not sure about the conclusions
Is this going to end up as a feature with a limited area of application because it turns out the implementation is an optimisation for particular cases?
Anyway whatever it is that chip XYZ does better than the rest this does not mean that customers will automatically migrate to it. It's a nice headline but companies won't be migrating from Oracle to MySQL anytime soon just because of better locking performance.
Keep the swearing coming.
Neither Erlang Not TM Will Do
There are major problems with Erlang and functional programming in general. You can find out why at this link:
Transational memory may solve a couple of problems but, as Professor Edward Lee explained in "The Problem with Threads", multithreading is worse than most of you suspect. The problem has to do with the inability to deterministically prescribe the order of transactions. This makes debugging a nightmare. Transactional memory does not help. Indeed, TM makes the problem even worse, in my opinion, because of the need to reprocess the transaction in case of corruption.
The solution to the parallel programming problem is to do away with threads altogether. There is a way to implement parallelism that is 100% threadless. It is a method that has been around for decades. Programmers have been using it to simulate parallelism in such apps as neural networks, cellular automata, simulations, video games and even VHDL. Essentially, it requires two buffers and an endless loop. While the parallel objects in one buffer are being processed, the other buffer is filled with the objects to be processed in the next cycle. At the end of the cycle, the buffers are swapped and the cycle begins anew. Two buffers are used to prevent racing conditions. This method guarantees 100% deterministic behavior.
In order to solve the parallel problem, it suffices to implement this method at the instruction level and make it and inherent part of the processor itself. To find out why multithreading's days are numbered, read "Parallel Computing: Why the Future Is Non-Algorithmic:
Admittedly, this solution will require a reinvention of the computer and of software construction methodology as we know it. But there is no stopping it. The sooner we get our heads out of the threaded sand and do the right thing, the better off we will be.
I thought the humour may a hard read into an interesting one. Good effort.
> So the exact same syncronized code runs, but in an optimistic rather than pessimistic fashion.
I don't think that's the point. From what I've read, this offers an entirely different way of thinking about concurrency.
For example: consider that you have two operations, list_remove and list_insert, which by themselves are thread-safe. Traditionally, these can't easily be composed into a larger thread-safe operation. You'd have to write something like:
item = list_remove(list1);
The problem is that you have to consider every other flow in the program which might touch list1 and list2, and set up a mutex which they all honour. Forgot one and the program crashes in an occasional and infuriating way.
With STM, you write:
item = list_remove(list1);
and that's it. Concurrency no longer affects your entire program globally; it's defined locally to where it's needed. Amazing.
Of course, performance *is* related to this. Naively you could implement atomic() using a single global mutex, like the "BIG GIANT LOCK" that FreeBSD used to have, but that kills concurrency. So to get good concurrency the hard work is in having lots of little locks and making sure that they are all used correctly.
STM does this for you - you effectively get the finest-grained "lock" needed for your atomic operation.
It doesn't actually lock, but rolls back and retries if the transaction was stamped on by something else. In practice, retries seem to be needed only occasionally.
None of this stops you having to understand concurrency though. You still need to know which bits of code need to be wrapped in atomic(), and why.
It's a pity that some readers can't handle a little mild obscenity here and there, and even more of a pity that some companies can't handle their employees reading it. I read el Reg specifically because of the gratuitous humour, it breaks up the monotony of work.
People should just relax, it's not like el Reg has some Paris Hilton fixation or something...
I'm liking Ted
A lot of people are complaining about the language, which is a bit surprising considering this is El Reg. I would agree if it was just profanity without humour, but I don't think it is.
He's right about multi-threading skills as well. We do a lot of it here and there are some people who just get it much more than others.
Anyway, I like the article style. It's punchy and interesting, which is quite an achievement considering the relatively tedious subject. I look forward to seeing more.
The chap knew more than he alluded to. Interesting little read, even if I had to reset the vulgarity filters on the work proxy to read it.
What, there's no single threaded spagetti code out there?
Single threaded programs are deterministic and composable. That's hasn't exactly made them all bug free.
Deadlock is actually one of the easier problems to debug. Typically a lock hierarchy is used to avoid deadlock. Of course sticking it on after the fact is problematic. But that just highlights the fact that threading requires working things out before hand. You can't just tack it on after the fact. Especially by people who don't know what they're doing.
good article - and it's a real shame people are still sensitive to words which have randomly been selected as 'swear words'. To me, words are words so I could care less.
unfortunately this is probably more of a reflection of the sensitivity of your audience than the article itself
First thing on here I've really laughed at in a while!
Good article and good language !
Godd article on an indeed interesting topic. By the way, SUN said, 11 years ago, they would have compilers to automaticly generate threaded code better than devs on their 64 CPUs systems. Didn't happen ... This approach seems a lot more promising.
As what the difficulty is, it's mostly that each mutex kills the speedup very rapidly, at least in computing programs.
As an answer to language nazis, I only counted:
1- 5 occurences of "fuck"
2- 3 occurences of "shit"
3- 1 occurence of "fellatio"
1 is common in english you don't speak proper english without it, 3 is also accepted any place I've worked in, so what might be the problem ? Apart from 3 never happening to them ?
AC, don't want to exhibit my sexual life to coworkers, and obligatory PH icon, because she did. To everyone with a bittorrent client :-)
I don't this the issue is that people are being sensitive, as much as they are reacting to the unprofessionalism displayed by the author. You wouldn't use such language in a document you write for work, or in school/university work - at any level. The reason being that it detracts from the content and reduces the credibility of the message - as we have seen here, with so many of the responses being about the language, not the topic itself.
Why the detailed information about a processor that is about to be cancelled?
Transactional memory did not work in the first rev of the ROCK chip and we have heard absolutely nothing about the second rev, which means it still does not work.
Sun cannot afford to do another rev and will end up just OEM'ing Fujitsu forever or trying to sell the company to them.
Given it was an article aimed and hardcore coders, and given the hardcore coders I know pretty much speak like that, I don't see the problem.
It was an interesting and entertaining article, and I hope the author has more on the way.
Threading isn't hard
You just have to use your brain when doing it, so you can figure out your strategy for dealing with shared resources.
People have being doing this with multi-process for decades, and multi-threading for about a decade.
I don't get this attitude that threads are difficult and error prone, though I come across it a lot. Perhaps more people should have sat in that class rather than declaring "fuck it, I'm off".
That's not to say I'm perfect, ask me what happened in compiler engineering class...
I <3 Posix
@Good article and good language
"[fellatio] is also accepted any place I've worked in"
Damn, I've been working for the wrong companies...
Did you get around to reading that paper you quoted above? Only, when I asked this same question before you called me a gutless thread-monkey, which didn't clarify anything. Although it leaves the impression you didn't.
The I-don't-want-to-think crowd
It might save your ass and make some things easier to develop in low-load scenarios, but just be careful your dead-locks don't turn into spin-locks when two or more competing transactions keep rolling each other back. Good luck debugging that.
Answer to Chris: the f words used on this page are triggering the content filter on the Web connection in the educational institution where I work. At present, only this page is being blocked, but if such language becomes more common, the whole domain may be blocked. This would result in my students being unable to read the article and form their own opinion about the language.
I personally think it is possible to write about developments like this without gratuitous use of swear words and with a less 'flip' presentation style (thus saving words), but I accept that style is a question of taste. Web filtering policy isn't and is hard to get changed.
"To me, words are words so I could care less."
Your brain disagrees with you on this.
Much as we may like to think that we're above/immune to being offended and can take in our stride words that derail others, its just not true. You can put people in a fMRI scanner and see different parts of their brain light up in real time in response to obscenity. Regular words light up the higher language centers primarily, obscenities also light up the emotional centers all the way down to the primitive reptilian stem. Good lay article here: http://people.howstuffworks.com/swearing4.htm
And no, you are not an exception, however much you may think frequent exposure or usage has inured you. No, really you aren't.
Fascinating organ, the brain.
bi-curious threading model
I used to think threads were hard until I discoered the aboe in a Stroustrop article. The basic idea is to embed elementary lock awareness into each of the threads, hae it run in a superisor-client process pair, and a bit of IPC to make each thread aware of locks being taken which interrupt its game-plan. The two processes then get switched into 1-on-1 mode where they play a game of naughts and crosses to break the deadlock. If that fails, they can escalate up to defcon and beyond-defcon leels, although since the BD leels take place in a post-Strangeloe-ian idiom, you often end up back where you started, with the obious difference that instead of worrying about how threads interlock, you're now left puzzling how hydras can be folded flat on the table.
Some people are commenting that the language takes away from the article, it's unprofessional, blah blah blah - but they appear to be completely ignoring the posts to the effect "the language made a tedious topic more palatable" Doesn't that mean that it didn't take away from the article? And if you consider a journalist's profession to be (in part at least) disseminating information to people... not sure if it would count as unprofessional either. Don't get me wrong - if you don't like it you don't like - I'm not saying there's anything wrong with not liking it.
For the web proxy crowd... if ssh is open on your firewall... well nuff said ;)
Regarding MRI's - isn't that kind of thing subconscious? So wouldn't it depend on which "me" he was referring to as to whether or not he and his brain are in agreement?
It would seem that your organisation needs a more enlightening approach to web filtering. Please don't dismiss this as a flip remark. I'm being serious. Filtering based on a few words from a table is an extremely prescriptive method of censorship.
You mention that its an educational institution but don't mention the level. I'm going to assume that its secondary education or higher. If that is the case then the little darlings are hardly likely to be harmed by the language in the article.
"Regarding MRI's - isn't that kind of thing subconscious?"
The concept of a distinct conscious and subconscious is a false dichotomy, modern brain science is teaching us.
In reality your brain is more akin (WARNING: fallible analogy ahead!) to a computer running a bunch of foreground and background threads, and sometimes the threads interrupt each other, bogart all the resources, or even lock each other, causing a "rollback" and start over. Hmmm, that reminds me of an article I read somewhere recently...
"My brain? That's my second-favorite organ!" -- Woody Allen
Why not use a database
I nowadays always program distributed shmem protocols using the DB2 client to a shared DB2 database. It works wonderful and I can use the same interface for all programming.
@David Hicks: Threading isn't hard
- and others of that opinion.
My experience of threading is limited to two cases. One was my own work which despite being a simple (almost trivial) server, scrupulously thought through, very carefully implemented and well tested, turned out to have a race condition.
The second is even less pretty - debugging someone else's race condition. Three solid weeks trying to reliably reproduce it. Which I finally did. And fixed it. And it turned out to be *a* race condition... not the one that was causing grief... I wept.
My conclusions are that, if I can snafu my own threading despite great care then it's systemically hard enough to worry me. The second is that, to many, if it doesn't seem to have a race condition then it's good enough to ship. Someone else can pick up the pieces. I suspect this is the majority case.
I'll stick my anonymous neck out and say that perhaps declarative statements of required behavior are required, not TM/semaphores/whatever. Seriously high-level specifications, which may compile down to whatever is best. TM is like semaphores/mutexes etc. It's just a detail.
But that's IMO only.
Keep it up.
Maybe I'm just a foul-mouthed, ADD riddled, bitter codemonkey , but that was the best dev article I've read for ages.
A whole fucking page of shite and the twat still doesn't fucking explain what the fuck he's on about.
Sorry, I can't fucking help it, a combination of tourettes and too much Gordon fucking Ramsay has messed with my fucking head.
So what is transactional memory?
This is for NEW software, not old databases
I'm sure Oracle and Microsoft have put in all the fine grained locks that a SQL database can possible use. They went through the pain and the bugs, and it's done now. Transactional memory is in no way shape or form faster than fine-grained locks, which by far are the most efficient implementation.
Transcational memory is NOT faster than fine-grained locks. It's just way easier. It's a boon for new software, and developers will like it. But to say that MySQL will suddenly leapfrog over age-old databases that have perfected their locks is just a non-sequitor.
language kills it
As others have pointed-out, this is a GREAT way to get the Register blocked at work.
On our developers network the Reg is ALREADY blocked, while the Inquirer is NOT (don't ask me, it's the net guy's idea).
Sorry, I don't want to wade through profanity at ANY site. It simply isn't polite and it definitely isn't necessary.
Clean it up and I might read it. I certainly can't post any references TO it anywhere.
Web filtering policy
Web filtering policy works like this:
Sites are blocked (apparently at random) UNLESS they're specifically excepted. Sites are specifically excepted if someone puts up a business case OR if someone in the BOFH department wants the sites herself.
@Bastard: you can work that out by reading the article.
Re:Ehrlang - please!!!!
I'm not throwing away all my investment in Java and C++ for yet another language.
Particularly when I can do all that Ehrlang offers already:-
JavaSpaces (transactional memory)
Jini (fault-tolerant networked PnP apps)
Rio (Service Level Agreements for Enterprise Scalability definition).
Codemesh (for native C++/C/.NET bind in)
Paris - 'cos even she won't jump the Ehrlang bandwagon
I've always considered "dragging your dick in the dirt" to be a negative, not positive little homily. Perhaps a better phrase for the intended result would be "...and Sun knows how deep the river is, not just how cold."
This is the second of the author's articles I've noticed. He is 2 for 2 in my book, and I want more.
Danger Will Robinson!
Why is it whenever I hear another story about how Sun's latest and greatest CPU/Server/Software is going to "change the game" all I can see is that robot off "Lost in Space" waving its arms around...
Surely by now everyone recognises the credibility gap between what Sun *say* they're going to do, and what they actually *deliver* ???