Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

1024cores

1024cores.net

Post reply on HN
Print view View original

1–10 of 19 posts

Re: 1024cores

#2

Post by viraptor »

> ..., atomic-free synchronization algorithms

Actually I'm not sure if it was supposed to be funny or serious. I see the funny "everything-free" list, as well as can imagine that there is some action you can do not atomically (relative to other actions) that gives you synchronisation.

Anyone?

Re: 1024cores

#3

Post by kev009 »

viraptor wrote: post #2

> ..., atomic-free synchronization algorithms Actually I'm not sure if it was supposed to be funny or serious. I see the funny "everything-free" list, as well as can imagine that there is some action you can do not atomically (relative to other actions) that gives you synchronisation. Anyone?

The speaker admits his English isn't perfect; probably an error as much of the site seems geared toward lock-free _atomic_ operations.

Re: 1024cores

#5

Post by sgt »

Interesting, but seriously, take those ads off. Are you expecting to make money off of this? Even if you did, it would be pocket change at most.

Re: 1024cores

#6

Post by dkersten »

viraptor wrote: post #2

> ..., atomic-free synchronization algorithms Actually I'm not sure if it was supposed to be funny or serious. I see the funny "everything-free" list, as well as can imagine that there is some action you can do not atomically (relative to other actions) that gives you synchronisation. Anyone?

I'm not quite sure what you mean, but synchronization without atomic operations is possible.

An example of mutual exclusion, without any atomic operations, taken from the book "The art of multiprocessor programming"[1] is (paraphrased) as follows:

Two threads, A and B, want to access some memory. Each thread has a flag.

When thread A wants to access the shared memory:

    Set flag A
    Wait for flag B to become unset
    Access memory
    Unset flag A
When thread B wants to access the shared memory:

    Set flag B
    While flag A is set {
        Unset flag B
        Wait for flag A to become unset
        Set flag B
    }
    Access memory
    Unset flag B
Obviously this isn't a general purpose solution, but rather an easy to understand example demonstrating that atomic operations are not required.

[1] http://www.amazon.com/Art-Multiprocessor-Programming-Maurice...

Re: 1024cores

#7

Post by codex »

So far, nobody has mentioned the author's C++ based race detection tool. Conceptually it is similar to Corensic's commercial product, Jinx (http://www.corensic.com) but practically Jinx supports more languages, doesn't require recompilation, and is most likely much faster.

Re: 1024cores

#8

Post by DaniFong »

sgt wrote: post #5

Interesting, but seriously, take those ads off. Are you expecting to make money off of this? Even if you did, it would be pocket change at most.

I would add -- if you're expecting to make money off this, you're probably better off advertising your own consulting services -- at suitably high rates. You're the expert now... :-)

Re: 1024cores

#9

Post by tedunangst »

dkersten wrote: post #6
viraptor wrote: post #2

> ..., atomic-free synchronization algorithms Actually I'm not sure if it was supposed to be funny or serious. I see the funny "everything-free" list, as well as can imagine that there is some action you can do not atomically (relative to other actions) that gives you synchronisation. Anyone?

I'm not quite sure what you mean, but synchronization without atomic operations is possible. An example of mutual exclusion, without any atomic operations, taken from the book " The art of multiprocessor programming "[1] is (paraphrased) as follows: Two threads, A and B, want to access some memory. Each thread has a flag. When thread A wants to access the shared memory: Set flag A Wait for flag B to become unset Acce…

That only works with coherent in order memory operations. Once you add the appropriate memory barriers, it looks a lot more "atomic".

Re: 1024cores

#10

Post by zerothehero »

chrisaycock wrote: post #4

The "many core" problem is this decade's C10K. I look forward to more expert discussion on scaling across massively multi-core architectures.

Is it really? Scaling today means running on more than one machine (google, facebook, twitter, etc.)

That means no shared memory. He helpfully makes this distinction on his front page ("I'm mostly interested in shared-memory system, so if you are looking for information about clusters, web-farms, distributed databases and the like, it's the wrong place")

According to Google's Jeff Dean, "to Google, multi-core computers look like separate servers with really fast interconnections" (i.e. memory).

So if you are running your applications on many machines anyway, you might as well drastically simplify your code by writing it "single-threaded" and running #cores copies on each machine.

Post reply on HN