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.

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...

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

The language detracts from the message. Do you normally swear at people you've just met?

(Maybe you do).

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.

@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/

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.

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!

James

Getting 3rd parties to provide complex functionality works as the author describes for the vast majority of the time. It's great - you don't have to code the hard stuff, it just does what you tell it and you don't have to worry about how.

However, just 'cos it's handed down from on-high doesn't make it bug-free. I can recall a couple of occasions when I've encountered mysterious bugs in 3rd party functionality... I can recall them because they each caused me more pain than any other technical problems I've hit in the last (nigh-on) twenty years!

In each case the provider (two different ones) did not want to know and claimed it was a problem with our code, a theory I had to exhaustively explore before discarding. I then had to understand the theory behind their functionality, reverse-engineer the way they had implemented that functionality, deduce the bug without access to their source code and then devise (and convince them to implement) a practical solution.

On the up-side this left me with an indelible understanding of bidirectional linked-lists (looooong time ago!) and record locking which is considerably deeper than I had previously. Then again, I didn't really *want* to understand them in that much detail.

It's a lot easier to find bugs when you've put them in yourself and you don't have to look for them blindfolded! :-)

Bottom line? If someone else is doing the hard stuff for you then that's cool when it works (which, most of the time, it will) and it'll save you a lot of time. But don't cut class just yet, 'cos when it goes wrong (which it eventually will!) you're in the brown and sticky!

Paris - 'cos she's had more than her share of deadly embraces!

http://plan9.bell-labs.com/magic/man2html/2/thread

(available for Lunix too via http://swtch.com)

CSP ftw!

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.

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.

There are major problems with Erlang and functional programming in general. You can find out why at this link:

http://rebelscience.blogspot.com/2008/07/erlang-is-not-solution.html

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:

http://rebelscience.blogspot.com/2008/05/parallel-computing-why-future-is-non.html

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:

mutex_synchronize(**what**) {

item = list_remove(list1);

list_insert(list2, item);

}

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:

atomic {

item = list_remove(list1);

list_insert(list2, item);

}

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...

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.

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.

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.

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!

To you, words are words so you *could* care less?

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.

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.

www.sunsucks.com

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.

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

"[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.

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.

http://msdn.microsoft.com/en-us/magazine/cc163715.aspx

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.

Pirate, t'fuck

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

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.

- 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?

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.

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 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.

So...

@Bastard: you can work that out by reading the article.

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.

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

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* ???

This way to the interweb, old bean:-

<http://en.wikipedia.org/wiki/Software_transactional_memory>

Since when has Maddox been writing for the Reg?

How come I didn't have professors like this?

I have no idea what he said, but I'm enjoying imagining him in chaps and black boots.

...and I've been a baaaaad student.

all the real coders have always been alcoholics, live in a cave and listen to metal, some "offensive" words are in the coders nature, real hackers piss in pots, not wear a suit like a movie

This looks like another Sun feature sell, just this time Sun are so desperate they're starting even before they got the chip out of the door! For those that don't know, here's how it works:

Sun invent a technique, usually a kludge, to get round a technical issue. It doesn't matter if it's actually needed by other vendors' CPUs/software, Sun have to use it so they pass it off as the best thing since sliced bread. Their salesgrunts turn up and try to get you to compare products based around the feature set they want you to concetrate on, which - surprise, surprise - are all those kludges Sun is trying to pass off as "innovations". The best way to derail this process is simply insist on a shoot-out, where you quickly see that Sun's "innovations" for the kludges they are, and your boss pats you on the back and takes all the credit for saving the company a shedload of money by buying HP, IBM, Dell, Uncle Tom Cobbley Co......

And even with the usual Sun CPU slippage, there's no way that MySQL is going to be able to catch and match Oracle for features and performance, even if Sun manage to maintain the flagging interest in Rock for another couple of years. Sun need something now, the customers are way past getting restless waiting for Sun's promised land.

"...words are words so I could care less..."

no. you COULDN'T care less. why do americans always get this wrong? think about it if you 'could care less' that means you must care a bit. if you 'couldn't care less' then you mustn't care at all.

jeezus! - it's not fuckin' brain surgery!

"why do americans always get this wrong?" - It's a conspiracy - we do it solely to annoy the British.

Nah, the real story is that we used to say we had invented the phrase "Couldn't care less" but Brits kept calling us out on it and saying that we claim to invent everything - so we changed it a bit to give our claim more credibility.

Ok ok, so the closest thing to the *real* answer is probably here:

http://www.worldwidewords.org/qa/qa-ico1.htm

QMutex m;

{

QMutexLocker lock(&m);

MyObject obj = myHashMap.get(key);

obj.setSomeValue(x);

myHashMap.remove(obj);

myList.add(obj);

}

Result: same as "atomic" and just as easy. It also releases the lock when an exception occurs.

I'm not sure what all the fuss is about.

The author doubtless fears pointers. Threads are not difficult or hard: they merely require more planning than single threaded code.

Profanity is not inherently amusing. Unexpected or incongruous profanity can be funny but it gets tired very quickly. Spoken profanity is easier to make funny than written profanity - which almost never works.

Wit is much better than profanity and the author should strive to acquire some.

I swear if I see one more article like this I will never ever visit The Register again. I know that expectations for quality of written word are pretty low these days, but come on ...

FYI, published comparison of transactional memory and locking, expanding on James Anderson's comment:

http://www.rdrop.com/users/paulmck/scalability/paper/TMeval.2007.09.24a.pdf

http://www.rdrop.com/users/paulmck/scalability/paper/TMevalSlides.2007.10.16c.pdf

And a revised presentation based on subsequent transactional-memory work:

http://www.rdrop.com/users/paulmck/scalability/paper/TMevalSlides.2008.03.04a.pdf

A revised version of the paper is in the works.

Apologies in advance to those who prefer their technical information sprinkled with lots of profanity. Can't have everything!!!

It was hard to tell in amongst the author's bed-wetting inferiority complex.

Anyone who has obviously failed miserably at ever writing correct thread-safe code should not be writing articles about writing correct thread-safe code in the first place.

And, yeah, the atomic { } juju.

'Cuz the rest of the world has only been doing this in C++ for about 10 years now. And we didn't need Transactional Memory for that.

My memories of a 1950's childhood don't include grizzled veterans swaggering around spewing obscenities in every direction. My memories are almost completely of quiet, earnest, polite men, gentle men and gentlemen, many of whom had been to hell and back. A pediatrician who had bombed Germany, a bus driver who fought in Italy, a neurosurgeon who was a sniper in the South Pacific, an engineer who fired cannon for Patton, and many others whose stories I never heard.

So if gratuitous obscenity is not the hallmark of manly discourse, what does it indicate, then? Someone please fill me in.

You could mine the irony of posting a comment without reading

"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."

Therefore, being a good programmer, you will immediately recognise that (a) you had best double check you are using the same mutex for all the list1 and list2 accesses; (b) test specifically the cases where obscure list accesses occur as well as the common cases.

Further, you do not "have to consider every other flow in the program which might touch list1 and list2" if you build the list as an instance of a class that controls it's own access - if you put the mutex inside the class. Someone else pointed out the basic idea with some Qt code above.

---

Finally, there is always OpenMP available for those people incapable of handling something like Posix threads or Win32 threads.

Though how one could fail to use Win32 threads properly is beyond me: IIRC there's only one mutex type but almost anything can be waited on.

AC @Kevin, thanks for explaining the actual benefit of the atomic construct.

That would indeed be a very welcome help - and it's way more elegant than locks.

Those who say multi threaded programming is not hard simply don't understand it. That's fine, just don't keep repeating it's not hard, because it is.

When I look at threaded code I see a billion billion possible execution paths. Mutexes make it manageable and make it work, and most threaded code I have debugged had errors but the possibility of hitting them was small enough that it didn't matter. There were bugs, but the code worked for all people could see. And that's even with the most basic multi threaded apps.

The thing to remember is: As long as the threads don't interact, there are no bugs. So you only need to keep the interactions to a minimum and then things will work.

Your frustration at language usage begs the question: why can't you cope with the fact that English is an amorphous dynamic thing that sometimes dosn't follow logic.

To believe that your way is the right way is a fallacy because language is suppose to have multiple meanings in different circumstances.

-- with love from America.

"why do americans always get this wrong?"

Why are all Brits always stiff-necked stuffed shirts?

Oh, they aren't. Hey, I'm an American and I couldn't care less. Guess what? I'd say at least 50% of us know the correct way to say that, and if you think we ALL get it wrong, it's because you're ignoring the times we get it right.

Sorry to disappoint you.

In fact, it's one of my pet peeves. I won't name the rest less I be accused of ranting. Except the one about people promoting stereotypes.

Thanks for painting me with that continent-wide brush.

Since I'm here ranting, I should mention that I enjoyed the article, and agree that the presentation added quite a bit of fun to an otherwise dry subject. I will say cautiously that there are ways to avoid using filter-triggering words while maintaining the tone. I personally was neither affected nor offended by the language, but I understand why people would be. Perhaps gratuitous use of swear words could be avoided?

On the other hand, when one article in hundreds or even thousands triggers the swear filters, how likely is that to cause blocking the entire site? Or are we afraid that if one author does it, they all will start? Are we projecting from one to infinity?

Just a thought.

Forgive me if I'm being abrupt and abrasive tonight. It's been a bad day. If it helps, I AM making an effort to avoid being a total flaming jerk. I hope tomorrow is better, I have a job interview.

"Was there content in this article? It was hard to tell in amongst the author's bed-wetting inferiority complex." .... By Andrew Posted Monday 28th July 2008 23:26 GMT

More than just a little, Andrew, ... and judging by the comments, much appreciated.

And then there are also all those submissions, cored in other tangents, which are not displayed in the thread/lying on the cutting room floor.

but then so do all those design patterns at first glance.

Except a singleton is just a way of providing global variables, which fails completely and badly, in a multiprocess system, and global variables are mostly bad anyway; and a decorator is little more than "adding another member variable." In fact the more I look at that book, the more I realise it's stupid shit designed to look clever whose real purpose is to make the authors rich, and to give the flowery brigade of implementation agnostic suit wearing architects something to talk about over their Frappacinos.

The problem of course comes as soon as you do multi process work, and who doesn't.

I do like it though, but it's not exactly Linq is it?

Love it!

It needs more swearing. I have added 'horsefucked' to my lexicon.

Thanks!

I would love to agree but I'm not american.

Infact, the phrase has its roots more in irony than in logic i.e. we don't say "I couldn't care less" despite its literal implication. We actually say "I could care less" with the implication towards the missing phrase "... but not much less!"

There is much discussion on numerous websites around the origin/intent of the phrase though so please fee lfree to browse.

On the subject of gramatic peeves though, as a mathematician I can never understand why mathematical sciences gets shortened to the singular (math) in the US rather than the traditional maths?

The article shows deep misunderstanding. Tx memory can be used to implement synchronized keyword in JVM quickly. However, how a feature of one specific CPU can be introduced to Java as a new keyword is beyond me - think of how that would be implemented on x86... So no, guys, you will not be able that Java code.

Ales

>how a feature of one specific CPU can be introduced to Java

>how that would be implemented on x86

It would be implemented in software in the JVM.

On compatible hardware that would go straight through to the machine largely unhindered, thus you would get dramatically better performance on Sun boxes than on x86 boxes. Something Sun might like.

Oh shit, forgot the fucking profanity.

The easiest way round this is to avoid it altogether!

Use a framework CICS, J2EE or ActiveX etc. that handles most of the parrallelism issues for you.

Use some of the very wonderful queue management software such as JMS, MSMQ to use queues to manage parrllel workloads (scales very nicely across multiple machines!).

Use Beowulf, or your "grid" of choice to impelment a MAP/REDUCE solution.

If none of the above work then you need to multithread, you need to learn how to do it properly, if possible use C and POSIX threads rather than Java threads, as C is a better language for this bit twiddling stuff and the POSIX libraries have more facilities and have stable (10 years plus) implementations.

Threading is not hard. It just requires a little bit of play and a lot of thought.

Maybe its because I'm relatively old by today's script kiddie programmers perspective. Maybe its because I stuck around the university an extra couple of quarters to take classes in OS theory and design. (Showing my age... I learned on Xenu (Doug Comer's teaching OS). )

Today's students have a lot more tools at their disposal. Some of these tools tend to dull the mind. Its easier to implement a Gof Pattern than to think about what it really represents.

If I were in a University setting, I'd try an experiment. Take a Gof pattern, define the problem, the constraints and let the student come up with their own unique solution, code it and then explain what they did and why. This way then are forced to think about the problem and a solution.

Software engineers should be taught to think rather than regurgitate. Most of the team of developers I work with today are in their 20's with maybe one over 30. Most are H1B. Most don't think about their work. That's your problem.

Just my "expurt" opinion.

-G

There is indeed; it's called MPI.

They a nuisance aren't they those foreign "script kiddie programmers" that "don't think about their work."

Heck, Should kick 'em out o' duh country wit a butt full o' buckshot. Yeehah!

Excellent article, much appreciated, particularly the humour content.

I've been looking into TM for a while now and it does look like a very promising alternative to the nightmare of locks. Intel's STM compiler is a good way to get started with it.

For anyone who still claims threading is easy, I can only assume they have not really been doing very much. We are still finding bugs in our threading libraries written a decade ago and gone over with a fine toothcomb several times since. It is insanely hard. As further proof, I would offer up the fact that almost every threading library or toolkit I have used, be it native threads, OpenMP or other, has contained threading bugs that I have hit. If you consider that the guys writing these libraries and implementations do this stuff full time and still get tripped up, it shows how hard it is.

The best example I have is that one of the third party tools we use to search for race conditions was not working for us. The vendor finally fixed it and reported, with some embarrassment, that the problem was a race condition in the tool itself.

In terms of grammatical peeves, I agree with the "could care less" griping, and I raise it with a "lowest common denominator" when they really mean highest common factor.

Sure. Some people use MPI on multicore chips.

But, LOL, there will still be some people that will complain that MPI is too hard!

TX memory is related to coherence protocol in multiprocessor machines - does anybody else want this cacheline? No? Your mutex succeeded. Yes? You must fall back to full mutex impl.

So that atomic is only for memory operations not for a block of Java code:

atomic {

webservices call to EBay here "pay something"

globalString = ws.getResult();

}

what if that atomic block fails as a result of attempt to write to globalString? Will JVM retry that code?

>It would be implemented in software in the JVM.

That would be really achievement. Copy on write of OS memory pages, false positives of dirtying the same page but different objects. Even classloading can happen in piece of Java code and you may not know it.

Somebody from Sun JVM team could comment on plans...

Good God! NO!

/runs screaming from HPC class in direction of pub

>>It would be implemented in software in the JVM.

>That would be really achievement.

It's a virtual machine, if you can do it in hardware you can do it in the virtual machine much more easily.

It might be too slow to be useful though, but that's Java.

>what if that atomic block fails as a result of attempt to

>write to globalString? Will JVM retry that code?

Well, it could retry indefinitely effectively blocking, or it could raise an exception.

It would depend on precisely how they defined the 'atomic' keyword.

I would expect an exception and for the handler to retry.

Nothing like a bunch of pompus pussy's saying the language is harsh. Fuck, I play CS:S where you blow up people, headshot opponents, and you get morons that say, "stop the cursing", well fuck, if a subject deserves some cursing such as programming, then I say, shit yea, the language fits, so fuck it.

Morons that think they are better than everyone else say that cursing is bad. It's not if the time is right. It's natural, just like fucking your wife. Whose wife? Oh well, fuck it.

If you don't like my language, then, kiss my royal white American ass. And kiss it softly please. Your morals are not my morals. You are the same people that think your religioin is better than mine, that your family is better than mine, that your car is better, that your home is better, well, FUCK YOU. How does that feel, sure feels good to me. And by the way, I think programmers are the under appreciated 'plumbers' of the world. Never piss one off, that's for sure. And if one wants to curse, then, motherfucker, let it out biatch!

This was the best article I've read all year, and probably will end up being the Article of the Year!!!

That was a great read, and the language made it funny and a bit intimate. I definitely relate.

I'm glad to see that theRegister still puts out stuff like this!

Perhaps instead of starting off computer science students with software and learning stuff, perhaps they should start off doing industrial robot programming.

For example robot A is doing a 22 second drilling operation, robot B has to grasp the part and give it to robot C so it can drill another hole, before said part is dropped in the 'finished' bin

robot A and C have to check with B that its finished the move, while robot B has to check with A and C that they are ready for the part.

Its easy to code when you can see the relationship between the various physical parts of the system and even easier to f*** up and end up with 2 holes drilled in robot B

robot programming is where I came from before starting to do software and it did give me a big leg up on threading stuff

But remember folks.... if threading was easy, any f**kwit could do it

Boris

<<who bought 'Concurrent Systems' by Jean Bacon(1st edition... not the easy peasy 2nd edition) and thinks its the best book ever written

I'd love to know why. May save me much trouble later. Ta

> So that atomic is only for memory operations not for a block of Java code

Correct - it can't cover anything which does I/O. So for output, you'd accumulate it in a buffer, and then output the buffer outside of an atomic() block.

TITS OR GTFO

Unless I'm really missing something, how does this help? A database's bottleneck is not thread synchronization, it's atomic writing to disk. Sure, transaction management of in-memory data is costly. But not nearly as costly as writing updates to disk in an infallible manner.

Maybe there are specific database scenarios that really benefit from this. But a read-heavy scenario doesn't have a lot of transactional overhead, and a write-heavy scenario will be bound by disk write performance.

So again, where does this help? I must be totally missing something. Can you help steer me straight?

http://blog.quinthar.com/2008/07/how-does-transactional-memory-improve.html

The part about transactional memory was interesting, the part where the author explains they're too thick/lazy to deal with concurreny (basic programming stuff, and how hard is using synchronized in java? ) not so interesting . Admittedly, the author is a CTO not a programmer thank goodness.

I tend to agree. IME on a well designed DB with halfway complex select statements it's the optimiser that's bottlenecking, which is CPU and not a thread issue.

Though does depend on the load and how it's used, obviously. I'm assuming predominance of reads rather than writes.

> "which is CPU and not a thread issue"

not exactly clear, sorry. AFAIK optimising is a functional matter - unoptimised query plan in, optimised query plan out. There's no need for any thread to communicate with any other in doing this, so no need for threads to communicate at all.

http://sunfeedroom.sun.com/ifr_main.jsp?nsid=c-7c3e5257:11b727a7d0f:-1e91&fr_story=FRdamp266994&st=1217399615860&mp=FLV&cpf=false&fr=073008_023335695_w7c3e5257x11b727a7d0fxw1e90&rdm=420218.1163818217

Interesting but definitely a work in progress.

A good reading list of cutting edge in STM approaches

http://www.cs.auckland.ac.nz/compsci703s1c/lectures/

At best I can code the "Hello World" program in about 6 different and equally old and unused languages so I had next to no idea what the authour was talking.

Still read the whole thing though as it was probably one of the funniest articles Ive read on The Register.

New job; much too busy to hang out around here these days...

I come back, and the first article I read is this one, and it's like I was never away.

Classic Reg. Profanity and all. Classic comments too. Seriously though people, some of you need to get lives. Okay, the style was more bootnotes and servers, but the content was still pretty fascinating. Objecting to the language is like rejecting the contribution of a colleague because he prefers not to wear a suit to work. Very early-to-mid-twentieth-century...

Long ago and in a distant land, the VAX processor had a small number of what were called "interlocked" instructions which essentially provided atomic operations on shared memory. The operations were fairly limited (queues and semaphores) but were intended to provide basic building blocks for higher-level synchronisation mechanisms in multiprocessing environments with shared memory.

Trouble is, this kind of thing adds another layer of complexity to bus arbitration, cache coherency et al and that affects performance. The more arbitrary you make the scope of transaction memory the more likely you are to have the same kind of problems with deadlocks that you get with traditional thread-based programming.

You could, alternatively, look at message-passing models, but you still end up with the old Mexican stand-off problem if your state tables are wanting.

Asynchronous programming *is* hard and there are no magic bullets. There will be a class of problem for which this approach has advantages - but there will be plenty for which it has not.

...then don't move to China.

If you don't like swearing, then never leave the house or go on the internet or turn on any communication device or interact with other people in the world at all, ever. Simple. Then you won't be offended all the time.

This was a great article, made me laugh, was interesting too, well written and not utterly lame, spineless and basically a government/corporate sponsored missive like most journalism. Keep up the good work I say and next time I want my pizza with extra swear words, thanks.

Also, to the puritan-maid brigade, do you realise that every time you and your fellow religionuts search the internet through some kind of sterilizing proxy software that you are in fact invoking an incident of each swear word for every page you seach for? Whoever wrote the software had to type in, or make reference to another typed resource, the words: fuck, c*nt, piss, toffee, horsefuck (kudos), etc. And so each time you access any page your proxy asks: Does this page contain the word 'fuck'? No, OK then, what about 'shit'? OK then, what about 'horsefuck' (kudos)? So you are invoking thousands of utterances of swearwords all de day long my friend. Whoops...you're going to hell boy! If a tree falls in the forest and no-one's there to witness it, does it make a sound? If every swear word you've ever thought of and many you probably haven't are invoked hundreds of times a day by your internet browsing, do they still cause offence?

Are you also a pro-lifer who'd gladly kill a doctor at an abortion clinic?

Also, who the fuck do you think you are, telling other people what they can and can't say and what they can and can't hear? Fuck off and go and live in hole somewhere. I don't tell you how to live your life.

The swearing in this article made it more interesting and more professional in my opinion as it reflects the reality of how frustrating programming can be and the reality that a massive amount of people in the world form certain phonetics into certain words that have been classified by a tiny-minded tiny group of people as swear words, nothing more. What makes them swear words outside of your self-induced offence? There's a reason why it's called 'being offended' or 'taking offence' because it's purely subjective.

Grrr...I wish someone would horsefuck Windows Fista.

Transactional Memory would save Windoze.....

The reason gates was pushing intel for faster and faster processors was windoze fails miserably at being multi-threaded.

Again try to not sieze up....

Yes applications can thread. The OS core however is a mismash of backward compatible crap that relies on wrapper after wrapper after wrapper API.

Let's say I have twenty badly written modules which don't thread very well but all must syncronize on a particular variable. Or perhaps I have an incredibly inadequate process scheduler that doesn't scale worth a damn past two cores....

If you don't believe me, then look at all the virtualization crap MS is pushing. You will never see windoze process monitor display 128 CPUs.... a "ps" on a sun T2+ does that easily...

I need backward compatibility but need scaling that doesn't break that compability. Transactional Memory puts the syncronization at the hardware level so a substantial amount of code just needs to be recompiled, not rewritten. This is not a problem with windoze cause a 300 megabyte service pack isn't scaring people as much as it used to.

So I predict, baring patent infringement, Intel will soon be touting "Hyper Transactional Memory" WOOOOOOOOO!

Let the flames begin....