Return of spinoza1111

[spinoza1111]

On Aug 2, 7:04 pm, "Chris M. Thomasson" <[email protected]> wrote:

[snipped a bunch of crap]

and I have
at this time no way of knowing whether it is, it would explain his
being online all the time. It's possible he can no longer get hired
as
a programmer owing to the fact that his only language is out of date,
and he answered one of those spammy ads to "make money with your
computer", and hit pay dirt.
These are only possibilities. If you can't reason with modal logic, I
doubt you're a competent programmer.
Go ahead and think up whatever you want. I am not so sure you can
understand
the type of programming I do. Humm...
Are you the auto parts catalog whiz? If so I think I do. Are you doing
space shuttle code or working for a rocket science Wall Street firm,
making sure the heat shield falls off (it's SO cool when it does that)
or that the tranche consists of deadbeat Dads who can't even pay for
the trailer? If so "I tremble for my country when I realize God is
just".
Reading Rainbow, you cannot understand English. So I really, really
hope that what I can't understand is auto parts, not rocket science,
here.

lol. Anyway, some people might compare the type of programming I do with
"rocket science", or perhaps compare it to juggling running chainsaws.

Well, let's see if you can accomplish a task that I consider to be fairly
easy. I want to create a reader/writer lock that has wait-free fast-paths on
both the writer and reader side. I want this lock to be 100% starvation-free
for both writers and readers. I want bounded time for both readers and
writers. Your not allowed to use CAS. After you accomplish that, I want you
to augment your algorithm to allow for conditional reader-to-writer
upgrades, and non-conditional writer-reader downgrade. You may use CAS for
the upgrade/downgrade, but not for reader/writer acquisition or release.
BTW, your not allowed to use any loops in the algorithm. Oh, one more thing.
I will make it really easy for you in that you do not have to document any
membars. Once you accomplish this task, then we can begin to discuss some
more exotic synchronization algorithms...

I'm sorry Chris but I don't feel
Like reinventing another wheel

This is not my area of expertise.

You MAY, from where I sit, not be aware that it MAY be impossible to
actually do this on arbitrary platforms. If the lock is a single
instruction on your system in machine language the code isn't portable
to another system.

But I concede that you aren't doing auto parts. The question remains
whether or not C is the right tool for what you're doing.

 

[Chris M. Thomasson]

messagenews:[email protected]... [...]

Well, let's see if you can accomplish a task that I consider to be
fairly
easy. I want to create a reader/writer lock that has wait-free
fast-paths on
both the writer and reader side. I want this lock to be 100%
starvation-free
for both writers and readers. I want bounded time for both readers and
writers. Your not allowed to use CAS. After you accomplish that, I want
you
to augment your algorithm to allow for conditional reader-to-writer
upgrades, and non-conditional writer-reader downgrade. You may use CAS
for
the upgrade/downgrade, but not for reader/writer acquisition or release.
BTW, your not allowed to use any loops in the algorithm. Oh, one more
thing.
I will make it really easy for you in that you do not have to document
any
membars. Once you accomplish this task, then we can begin to discuss
some
more exotic synchronization algorithms...

I'm sorry Chris but I don't feel
Like reinventing another wheel

Creating high-performance reader writer lock is not a waste of time. Heck,
even Sun Microsystems has an entire group working on synchronization
primitives. And guess what? They just released a paper on high-performance
read writer locks. They are using distributed counting technique to increase
scalability. There work in not in vain.

This is not my area of expertise.

You MAY, from where I sit, not be aware that it MAY be impossible to
actually do this on arbitrary platforms. If the lock is a single
instruction on your system in machine language the code isn't portable
to another system.

Actually, my synchronization code is portable to a fairly wide range of
architectures. I know the caveats, and I know how to work around them.

But I concede that you aren't doing auto parts. The question remains
whether or not C is the right tool for what you're doing.

I use a mixture of C and assembly language. C is low-level enough to allow
me to do what I want. Tell me, if I used C sharp, how could I ensure that,
for instance, data is padded to a L2 cache line and aligned on a L2 cache
line boundary? Do you know why that's important wrt synchronization
algorithms? Don't get me wrong, C# is a fine language and I do use it from
time to time. But, I can reap much better performance if I use C and ASM to
create synchronization libraries. I can then use that library in C#,
everybody wins.

 

[Chris M. Thomasson]

Reading Rainbow, what part of "metaphor" don't you understand? My
experience at Bell-Northern Research is that most developers fantasize
a risky and macho world while behind the scenes their work product is
so checked and monitored that they cannot take in fact the risks they
think they're taking.

I won't accept your challenge.

Okay. How about something else that I think is easy. Create a non-blocking
stack that only uses CAS on producer side, and make the consumer side
wait-free. I also want to see those membars!

:^)

It appears to me that you are
overfamiliar with specific technology and perhaps underfamiliar with
the basic science (think Dijkstra).

I am completely familiar with the basic science (think Hoare). I even hacked
together a construct in C++ that mimics the monitors and the `when' keyword
described by him.

What appears to be "progress" in
computer science is often the faulty elaboration of computing science,
usually in the foolish name of "speed" and sometimes in a deliberately
fraudulent manner.

Forget about speed for a moment. My advanced algorithms are all about
scalability (think RCU). However, the read writer lock I described is not an
advanced algorithm, it's rather simplistic.

I would note that my platform simply and elegantly supports
multithreading with a lock{} block and the ability to set semaphores.

Great. BTW, how are you implementing those semaphores? I know of a really
nice algorithm invented by Joe Seigh over on comp.programming.threads. It
has wait-free fast-paths, and it's fair. Perhaps it might be of use to you.
Also, if you ever decide to support message passing, I can turn you on to
many high-performance queue algorithms that outperform basically anything
else out there.

 

[Chris M. Thomasson]

Great. BTW, how are you implementing those semaphores? I know of a really
nice algorithm invented by Joe Seigh over on comp.programming.threads. It
has wait-free fast-paths, and it's fair. Perhaps it might be of use to
you. Also, if you ever decide to support message passing, I can turn you
on to many high-performance queue algorithms that outperform basically
anything else out there.

Perhaps my work can be of service to the runtime of your language. This is
why I like the low-level nature of C and ASM. People can use the libraries I
create to create higher level constructs. Heck, you can even use some of my
stuff to create the multi-thread synchronization scheme in OS kernels.

 

[Chris M. Thomasson]

Okay. How about something else that I think is easy. Create a non-blocking
stack that only uses CAS on producer side, and make the consumer side
wait-free. I also want to see those membars!

I forgot to mention that the stack should be unbounded.

[...]

 

[Kenny McCormack]

Creating high-performance reader writer lock is not a waste of time. Heck,
even Sun Microsystems has an entire group working on synchronization
primitives. And guess what? They just released a paper on high-performance
read writer locks. They are using distributed counting technique to increase
scalability. There work in not in vain.

I think you mean: They're work [is] not in vein.

 

[luserXtrog]

There's a coder named Chris Thomasson
Who's deficient in logic and has no funnybone
His responses are spam
Written under the influence of Diazepam
That unfortunate sod, Thomasson.

The rimes are nice, but there's no rithme.

 

[luserXtrog]

Creating high-performance reader writer lock is not a waste of time. Heck,
even Sun Microsystems has an entire group working on synchronization
primitives. And guess what? They just released a paper on high-performance
read writer locks. They are using distributed counting technique to increase
scalability. There work in not in vain.

I think you mean: They're work [is] not in vein.

ITYouM: Their (possessive pronoun)

 

[Chris M. Thomasson]

Any references on those queue algorithms?

Post over on comp.programming.threads for MUCH more detailed information.
Anyway, FWIW, here are some algorithms:


Here is one of the fastest unbounded non-intrusive multi-producer/consumer
queue's out there (created by me):

http://software.intel.com/en-us/forums/threading-on-intel-parallel-architectures/topic/66573


Here is a version in C#:

http://cpt.pastebin.com/f72cc3cc1


Please note that this has the same memory management properties that a
lock-free stack does.




Here is one of the fastest unbounded non-intrusive
multi-producer/single-consumer queues out there:

http://relacy.pastebin.com/f4ca417dc
(invented by Dmitriy V'jukov)


Here is the intrusive version:

http://relacy.pastebin.com/f1619ab91




Here is the intrusive unbounded version of a multi-producer/consumer queue:

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/c43d1197c8168b4e
(invented by Dmitriy V'jukov)


This version uses SEH to handle memory management.




Here is bounded single-producer/consumer queue:

http://pastebin.com/f693b64b3
(my me)




Here is bounded multi-producer/consumer queue:

http://relacy.pastebin.com/f4ec057ef
(by me)





if you want to add conditional blocking semantics to any of the queues
above, you can use my eventcount invention:

http://software.intel.com/en-us/forums/threading-on-intel-parallel-architectures/topic/66575





Here are some of the unbounded queues above in C#:

http://cpt.pastebin.com/f2c4d8412
(single-producer/consumer queue by me /w fast-path semaphore by Joe Seigh)


http://cpt.pastebin.com/f52dcc0fc
(single-producer/consumer queue by me /w eventcount by me)


http://heev.pastebin.com/f70a73f00
(multi-producer/single-consumer by Dmitriy V'jukov /w eventcount by me)


http://heev.pastebin.com/f270184be
(multi-producer/single-consumer by Dmitriy V'jukov /w eventcount by me /w
node cache by me)


http://heev.pastebin.com/f10399a09
(multi-producer/single-consumer by Dmitriy V'jukov /w eventcount by me /w
node cache by Dmitriy V'jukov)





Here is a bounded single-producer/multi-consumer queue by Amine:

http://www.colba.net/~aminer





Here is a dynamic work-stealing deque my me:

http://relacy.pastebin.com/f5bbceb0





Here is work-stealing deque by Sun Microsystems:

http://research.sun.com/scalable/pubs/main-10.pdf




Here is multi-producer/consumer queue by Michael and Scott (IBM):

http://www.cs.rochester.edu/research/synchronization/pseudocode/queues.html
(please note that my multi-producer/consumer queue beats this one to death)




http://webpages.charter.net/appcore
(Some of my experimental algorithms, pre-alpha)


BTW, my website has been referenced by both Sun Microsystems and Intel:


http://developers.sun.com/solaris/articles/chip_multi_thread.html
(search web-page text for "AppCore"; please note that this points to my old
site that has migrated to charter.net. I moved to South Lake Tahoe and they
still have not updated the link)



http://software.intel.com/en-us/articles/multiple-approaches-to-multithreaded-applications
(search web-page text for "Chris Thomasson"; please note that this points to
my old site that has migrated to charter.net. I moved to South Lake Tahoe
and they still have not updated the link)




My website has also been referenced in a lecture by a Professor Arthur
Goldberg in his Spring 2006 Syllabus. A speaker by the name of David
Buksbaum, SVP Development Manager of Systematic Trading, Citadel Investment
includes a reference to my website:


http://www.cs.nyu.edu/artg/internet/Spring2006/syllabus.html
(search webpage text for "David Buksbaum", then click on the link to the
lecture, then search lecture text for "AppCore").





I have also invented a new algorithm which I call "Virtually Zero-Overhead
Object Management" or (VZOOM) for short which won me a T2000 server from Sun
Microsystems CoolThreads Contest:

https://coolthreads.dev.java.net


Here is where I introduce myself to the contest managers:

https://coolthreads.dev.java.net/servlets/ProjectForumMessageView?messageID=11001&forumID=1797



Please note that the VZOOM algorithm I submitted was in a very crude
experimental pre-alpha status, and I still was one of the finalists. Here
are the papers I submitted in order to get accepted into the contest:

http://webpages.charter.net/appcore/vzoom/round-1.pdf

http://webpages.charter.net/appcore/vzoom/round-2.pdf


BTW, VZOOM also has a very high-performance memory allocator. There is an
algorithm in there that allows one to even transform single-threaded
allocator into scaleable multi-threaded allocator; no kidding:

http://software.intel.com/en-us/for...arallel-architectures/topic/61145/reply/65555



BTW, the proxy collector portion of VZOOM has a patent application out on
it:

http://www.google.com/patents/about?id=c6ybAAAAEBAJ






I could actually go on and on, but please, pay us a visit over on
`comp.programming.threads' where all the non-blocking algorithm experts hang
out.



We will be happy to consult you.



Thanks!


:^)

 

[Chris M. Thomasson]

Post over on comp.programming.threads for MUCH more detailed information.

I left out details on memory barriers for clarity. If you want to use one of
the presented queues, post a query over on `comp.programming.threads' and we
will elaborate about the memory barriers that your going to need.

[...]

 

[Chris M. Thomasson]

[...]

Here are some of the unbounded queues above in C#:

http://cpt.pastebin.com/f2c4d8412
(single-producer/consumer queue by me /w fast-path semaphore by Joe Seigh)

[...]

Sorry, bad link. Pastebin seems to have lost the post! Anyway, here is Joe
Seigh's fast-path semaphore with a slight modification by me (atomics and
membars handled by Windows API):
______________________________________________________________________
#define UNEXPECTED_ERROR(mp_exp) \
assert((mp_exp)), std::unexpected()

#define UNEXPECTED_ERROR_WIN() \
UNEXPECTED_ERROR(GetLastError() == ERROR_SUCCESS)


class semaphore {
LONG m_count;
HANDLE m_waitset;


public:
semaphore(LONG count = 0)
: m_count(count),
m_waitset(CreateSemaphore(NULL, 0, LONG_MAX, NULL)) {
if (m_count < 0 || ! m_waitset) {
if (m_waitset) CloseHandle(m_waitset);
assert(m_count > -1 && m_waitset);
throw std::exception();
}
}


~semaphore() throw() {
if (m_count < 0) {
UNEXPECTED_ERROR(m_count > -1);
} else if (! CloseHandle(m_waitset)) {
UNEXPECTED_ERROR_WIN();
}
}


public:
void post(LONG count = 1) throw() {
if (count < 1) {
UNEXPECTED_ERROR(count > 0);
}
LONG old_count = InterlockedExchangeAdd(&m_count, count);
if (old_count < 0) {
if (! ReleaseSemaphore(m_waitset,
(-old_count) > count ? count : -old_count, NULL)) {
UNEXPECTED_ERROR_WIN();
}
}
}


void wait() throw() {
if (InterlockedDecrement(&m_count) < 0) {
if (WaitForSingleObject(m_waitset, INFINITE) !=
WAIT_OBJECT_0) {
UNEXPECTED_ERROR_WIN();
}
}
}
};
______________________________________________________________________




This algorithm is portable to any platform with Fetch-and-Add or CAS.

BTW, VZOOM also has a very high-performance memory allocator. There is an
algorithm in there that allows one to even transform single-threaded
allocator into scaleable multi-threaded allocator; no kidding:

http://software.intel.com/en-us/for...arallel-architectures/topic/61145/reply/65555

Sorry, wrong link above, here is corrected link:

http://software.intel.com/en-us/forums/threading-on-intel-parallel-architectures/topic/61145



[...]

 

[Default User]

Richard Heathfield wrote:

Rather like yours in that respect.

Any chance we could get you to stop feeding yet another troll?



Brian

 

[James Dow Allen]

Hello Mr. Nilges!

You and I read the same newspaper; I know because I see your
Letters to Editor from time to time. They're usually well-argued.
It would be nice if you exercised the same care in your Usenet
postings.

Why do you pass on falsehoods about people? It's criminally
and civilly liable, and, it's wrong.

Yes, we agree again. Slandering people is wrong. But methinks
you are more the slanderer than slanderee.

... conduct manifests homophobia in that he likes to break
up conversations between typically male posters by telling one or the
other that the other is incompetent.

"Homophobia???" Check your dictionary.

I do believe that his and others' use of "troll" is the use of a
traditionally racist Nordic word that fits into the same types of
sentences as does "Jew".

The word "troll" becomes anti-Semitic??? Wow!!

Ed, I don't know what tickles your fancy -- you might try the girls
with
handcuffs and whips -- but whatever it is, try it for a few hours and
then repost. It will surely lead to an improvement.

James

 

[spinoza1111]

Hello Mr. Nilges!

You and I read the same newspaper; I know because I see your
Letters to Editor from time to time.  They're usually well-argued.

....if over-edited, I not being a prestigious chap. Thanks for reading
the abbreviated letters, however. I'd say the fact that I have passed
the editorial bar, which is set high at our mutual newspaper (a
prestigious world paper of record), along with the fact that I've
published articles and a book should give you pause before you make
certain assumptions that are made by others.

It would be nice if you exercised the same care in your Usenet
postings.

I believe I do.

Yes, we agree again.  Slandering people is wrong.  But methinks
you are more the slanderer than slanderee.

This is NOT the case.

You see, people see what's being said about them and their instinct is
to defend themselves, perhaps with equal force if hopefully with no
fraud. But as I have said elsewhere, other posters don't see the
sequence of events, and very often confuse a person vigorously
defending herself with the attacker, since they read a couple of
recent posts and jump to conclusions.

Furthermore, corporate life makes people less brave and less apt to
defend themselves, thus a vigorous self defense against a nasty,
enabling and/or snide comment, of the sort that Heathfield specializes-
in, seems like bad behavior. But note that the US Constitution, the
oldest written constitution in the world, recognizes the need of men
to have freedom of speech so as to defend themselves...whether against
"noble lords" or their bully boys makes no difference.

"Homophobia???"  Check your dictionary.

The dictionary is a poor guide to the meaning of words. Most truly
literate people learn vocabulary from reading books other than the
dictionary, for the lexicographer reports either his personal
understanding (as did Samuel Johnson in his Dictionary), or general
received usage, which is often just wrong, and lowest-common-
denominator in terms of insight.

Overt gay-bashing "homophobia" might be what the dictionary reports.
However, it is not the lexicographer's job to do social science, nor
to theorize that homophobes may be ordinary thugs enforcing norms
which society needs to enforce as a whole...but which the more genteel
are loth to enforce themselves. Homophobia may be a special case of a
common male inability to relate, connect and talk about feelings
EXCEPT in cases of war and stress under the buddy system.

The word "troll" becomes anti-Semitic???  Wow!!

Again, this is NOT what I am saying. I am saying that two major
theorists of anti-Semitism, Sartre and Arendt, have pointed out (Anti-
Semite and Jew: The Origins of Totalitarianism) that the Jew was a
target of convenience for the French anti-Semite in Sartre and the
German anti-semite in Arendt.

The French anti-semite transferred his unacceptable feelings of
weakness and failure onto the closest and most Other. Today these
feelings are transferred to Palestinians, made stateless in effect as
the Jews once were (Gazans are unable to elect a leader and have the
international community accept this: they are not given sovereignity).

Arendt's anti-Semite turned on the Jews because they'd lost princely
support once German states and after 1870 the Reich cultivated non-
Jewish sources of finance. They were targets of convenience. There was
nothing "essential" in the Jew to attract the hatred of the anti-
Semite in either case; indeed to hypostatize some magical power of
repulsion would itself be a species of anti-Semitism.

This means that anti-Semitism is anti- first and instantiated with a
target later, and that target could be Jews, Palestinians, or perhaps
in a minor way right here, the male poster's "idea" of the troll.

In Sartre, the anti-Semite constructs an image of the Jew built
introspectively out of his own unacceptable feelings of being weak as
well as is unavowable fantasies of power, the result being "der Ewige
Juden" who is, at one and the same time, a world banker and
contemptible little merchant.

In anti-trollismus, the male poster envisions the "troll" as he fears
himself to be: without friends, a crappy or nonexistent job, and no
girlfriend or social life. By calling posters "trolls", posters like
me who are outlier cases for the most part because we can write gude
wif gude gramer and speling, whose posts look different on their
screen because they resemble polished text and not random horse shit,
the male poster hopes that his own secret weakness will stay well
hidden.

Ed, I don't know what tickles your fancy -- you might try the girls
with
handcuffs and whips -- but whatever it is, try it for a few hours and
then repost.  It will surely lead to an improvement.

Been there, done that. Telling a guy to get laid is the usual answer
in an administered world to original thought. But we have all that
shit here in Hong Kong.

 

[spinoza1111]

superpollo said:


it is funny to see that trolls abund in every culture and language,
protected from shame by semi-anonymity.

in the italian math group (there is a guy
who says to everybody else that they are wrong because (he says) one and
zero are the same number, and then he goes on ranting in a way it is
impossible to cope with. and the troll is constantly fed (by mee too,
mea culpa).

then there used to be one guy that simply said  zero is not a number and
should not be used, and noticed the abuse about everyone that told him
he's an asshole. an so on.

but i must admit that this spinoza guy is of another league (for good
and for bad): at least he's literate.

bye- Hide quoted text -

- Show quoted text -

Gee, you're completely unqualified to address my points so you start
babbling about some other guy. So Musatov does this and this other guy
does that, and both are people with unusual idees fixe. How is that
germane to my concerns about the fraudulent promotion of C? My
experience with Nash taught me that "loonies" are not interchangeable:
each has his own story. I'm a loonie in the statistical sense (being
unusual and an "outlier" curve-wise) but there is an infinite number
of ways to be totally out of it. Furthermore, my experience at Bell
Northern Research and reading of Diane Vaughan's study of Challenger
showed me that entire communities can be statistically "normal" and
deviant at the same time.

Marcuse foresaw in 1970 that men would eventually, and willingly, line
up like sheep in rank order, with little computer programmers forced
to acknowledge the deep insight of fat men with more "experience" in
crappy programming languages. One Dimensional Man, like a character in
Edwin Abbot's Flatland restricted to one dimension, can only look to
his left and see someone a little bit richer and to his right someone
a bit poorer. He can't "process" characters who refuse to get in line,
so he reduces them to the simple category of "loonie".

 

[spinoza1111]

Edward Nilges was perplexed
Hostility was not processed
All because he couldn't see
His own expressed hostility

Ant labored mightily
With a thesaurus and rhyming dictionary
To produce almost acceptable
Poetry. Thus we see the fable
Of the rubber tree.
Ant missed the mark, in the dark,
Because I am perfectly aware of mine own
Hostility. This thing of darkness I acknowledge
As did Prosper his Caliban.

 

[spinoza1111]

Post over on comp.programming.threads for MUCH more detailed information.
Anyway, FWIW, here are some algorithms:

Here is one of the fastest unbounded non-intrusive multi-producer/consumer
queue's out there (created by me):

http://software.intel.com/en-us/forums/threading-on-intel-parallel-ar...

Here is a version in C#:

http://cpt.pastebin.com/f72cc3cc1

Please note that this has the same memory management properties that a
lock-free stack does.

Here is one of the fastest unbounded non-intrusive
multi-producer/single-consumer queues out there:

http://relacy.pastebin.com/f4ca417dc
(invented by Dmitriy V'jukov)

Here is the intrusive version:

http://relacy.pastebin.com/f1619ab91

Here is the intrusive unbounded version of a multi-producer/consumer queue:

http://groups.google.com/group/comp.programming.threads/browse_frm/th...
(invented by Dmitriy V'jukov)

This version uses SEH to handle memory management.

Here is bounded single-producer/consumer queue:

http://pastebin.com/f693b64b3
(my me)

Here is bounded multi-producer/consumer queue:

http://relacy.pastebin.com/f4ec057ef
(by me)

if you want to add conditional blocking semantics to any of the queues
above, you can use my eventcount invention:

http://software.intel.com/en-us/forums/threading-on-intel-parallel-ar...

Here are some of the unbounded queues above in C#:

http://cpt.pastebin.com/f2c4d8412
(single-producer/consumer queue by me /w fast-path semaphore by Joe Seigh)

http://cpt.pastebin.com/f52dcc0fc
(single-producer/consumer queue by me /w eventcount by me)

http://heev.pastebin.com/f70a73f00
(multi-producer/single-consumer by Dmitriy V'jukov /w eventcount by me)

http://heev.pastebin.com/f270184be
(multi-producer/single-consumer by Dmitriy V'jukov /w eventcount by me /w
node cache by me)

http://heev.pastebin.com/f10399a09
(multi-producer/single-consumer by Dmitriy V'jukov /w eventcount by me /w
node cache by Dmitriy V'jukov)

Here is a bounded single-producer/multi-consumer queue by Amine:

http://www.colba.net/~aminer

Here is a dynamic work-stealing deque my me:

http://relacy.pastebin.com/f5bbceb0

Here is work-stealing deque by Sun Microsystems:

http://research.sun.com/scalable/pubs/main-10.pdf

Here is multi-producer/consumer queue by Michael and Scott (IBM):

http://www.cs.rochester.edu/research/synchronization/pseudocode/queue...
(please note that my multi-producer/consumer queue beats this one to death)

http://webpages.charter.net/appcore
(Some of my experimental algorithms, pre-alpha)

BTW, my website has been referenced by both Sun Microsystems and Intel:

http://developers.sun.com/solaris/articles/chip_multi_thread.html
(search web-page text for "AppCore"; please note that this points to my old
site that has migrated to charter.net. I moved to South Lake Tahoe and they
still have not updated the link)

http://software.intel.com/en-us/articles/multiple-approaches-to-multi...
(search web-page text for "Chris Thomasson"; please note that this points to
my old site that has migrated to charter.net. I moved to South Lake Tahoe
and they still have not updated the link)

My website has also been referenced in a lecture by a Professor Arthur
Goldberg in his Spring 2006 Syllabus. A speaker by the name of David
Buksbaum, SVP Development Manager of Systematic Trading, Citadel Investment
includes a reference to my website:

http://www.cs.nyu.edu/artg/internet/Spring2006/syllabus.html
(search webpage text for "David Buksbaum", then click on the link to the
lecture, then search lecture text for "AppCore").

I have also invented a new algorithm which I call "Virtually Zero-Overhead
Object Management" or (VZOOM) for short which won me a T2000 server from Sun
Microsystems CoolThreads Contest:

https://coolthreads.dev.java.net

Here is where I introduce myself to the contest managers:

https://coolthreads.dev.java.net/servlets/ProjectForumMessageView?mes...

Please note that the VZOOM algorithm I submitted was in a very crude
experimental pre-alpha status, and I still was one of the finalists. Here
are the papers I submitted in order to get accepted into the contest:

http://webpages.charter.net/appcore/vzoom/round-1.pdf

http://webpages.charter.net/appcore/vzoom/round-2.pdf

BTW, VZOOM also has a very high-performance memory allocator. There is an
algorithm in there that allows one to even transform single-threaded
allocator into scaleable multi-threaded allocator; no kidding:

http://software.intel.com/en-us/forums/threading-on-intel-parallel-ar...

BTW, the proxy collector portion of VZOOM has a patent application out on
it:

http://www.google.com/patents/about?id=c6ybAAAAEBAJ

I could actually go on and on, but please, pay us a visit over on
`comp.programming.threads' where all the non-blocking algorithm experts hang
out.

We will be happy to consult you.

Thanks!

:^)

I'm not worthy! I;m not worthy!

Looks like a great stack o' stuff; I will look into it. I use
multithreading only in the most elementary ways.

But your accomplishments would have been greater had you used a
language other than C.

 

[spinoza1111]

...

I think you mean: They're work [is] not in vein.

ITYouM: Their (possessive pronoun)

Well, THAT took a while for you brainiacs to get right. You sure that
C doesn't damage the ability to use a more important language, such as
English?

 

[spinoza1111]

The rimes are nice, but there's no rithme.

Not if you read it in World Received Pronunciation or Britiish-posh.
If y'all read it like George Bush it is not rhythmic. Here is how to
stress it:

There's a CODer named CHRIS ThomasSON
Who's defICient in LOGic and has no funnyBONE
His reSPONses are SPAM
Written UNder the INfluence of DiazePAM
That unFORTunate SOD, ThomasSON.

Chris probably doesn't pronounce his name that way, but the use of
"bone" forces the reader to do so in an amusing fashion. The other
stresses are normal.

 

[Chris M. Thomasson]

[...]

BTW, if you give up, I will show you the answer. I invented a very nice
general purpose reader writer lock that can outperform most existing
native OS primitives (e.g., the NPTL).

Okay, since spinoza does not see any need to take on the challenge, here is
my read/write lock:



http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/65822



Here is a version which complies with all the rules of the challenge:

http://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/65822/reply/87849/




Here is a version of it which will work on any IA-32 platform which supports
POSIX (e.g., has semaphores), and GCC:

http://pastebin.com/f7d6677c6




You can test it's performance against the native read/write lock by simply
defining `USE_PTHREAD_NATIVE_RWLOCK'. Here are the results I am getting from
the test as-is on Linux Fedora Core 10. This mainly tests read performance.
Writes are VERY few and far between. So writer-to-reader contention will
probably never show up. Anyway, here is the command line I used to compile
my version:


gcc -Wall -pedantic -DNDEBUG -O3 rwmutex.c -lpthread


And here is the one I used for the NPTL:

gcc -Wall -pedantic -DNDEBUG -DUSE_PTHREAD_NATIVE_RWLOCK -O3
rwmutex.c -lpthread




Here is the relevant portion of the output I get from my version:

TEST RUN 1 of 2 RUNNING...
READERS ACHIEVED 249999 ITERATIONS PER-THREAD-PER-SECOND

TEST RUN 1 of 2 COMPLETED!!!
------------------------------------
TEST RUN 2 of 2 RUNNING...
READERS ACHIEVED 249999 ITERATIONS PER-THREAD-PER-SECOND

TEST RUN 2 of 2 COMPLETED!!!
------------------------------------




And here is the output I get from the NPTL version:

TEST RUN 1 of 2 RUNNING...
READERS ACHIEVED 133333 ITERATIONS PER-THREAD-PER-SECOND

TEST RUN 1 of 2 COMPLETED!!!
------------------------------------
TEST RUN 2 of 2 RUNNING...
READERS ACHIEVED 133333 ITERATIONS PER-THREAD-PER-SECOND

TEST RUN 2 of 2 COMPLETED!!!
------------------------------------




As you can see, my version is getting 116666 more reads
per-second-per-thread. AFAICT, that is a very significant number. Imagine if
those reads represented searches in a shared data-structure. Pretty nice
speed up over the native NPTL. Please note, I have test this under
OpenSolaris and Fedora Core 10. I have not tried it against the most recent
version of Fedora.



Enjoy!


:^D