The Future of C++ ?

[Chris Thomasson]

ARGHGGH!

void do_cow_cas(mystring_t const &src) {
mystring_lptr_t xchg(new mystring_t), cmp;

do {
cmp = s_buf;
if (cmp) {

Need to add this of course!!!

xchg->assign(*cmp);

xchg->append(src);
}
} while(s_buf.cas(cmp, xchg));
}

sorry for any confusion!

;^(...

 

[Chris Thomasson]

OK, as store is probably negligible, lock-free algorithm means saveing
one interlocked instruction, right?

for 100% uncontended case and single-word updates, yes. Keep in mind that
the overhead of the lock kind of skyrockets if it hits contention...

Also, keep this in mind, seems like you already are, but FWIW here is some
good rules to follow:

http://groups.google.com/group/comp.lang.java.programmer/msg/9af5f99388172527

http://groups.google.com/group/comp.lang.java.programmer/msg/e09c78f88d2b1d65


Sound good to you?

BTW, do you have some info how really are expensive those atomic
operations?

Not numbers... He is why:

http://groups.google.com/group/comp.programming.threads/msg/aeb7e857ef440520

[...]

Yes. Actually, after understanding the basic concept (that lock-free
still uses atomic operations, so it is lock-free, not LOCK-free), rest
is simple


But is not it more expensive in reality for String class? Without
explicit serialization, I can lock only variables that are shared
across threads, with 'strong reference', CAS costs will be omnipotent,
right?

Well, the cost of acquiring a strong reference is two-interlocked
instructions (uncontended), and the cost of acquiring a weak reference is a
loopless algorithm with one-interlocked op guaranteed. The cost of swapping
a global pointer with a local pointer is a loopless algorithm with
one-interlocked op guaranteed. So there are tradeoffs.

And keep in mind that if you stick to 100% COW the string algorithm that
your using need not have any synchronization of its own. The refcount
library will keep everything in order for you...

 

[Joe Seigh]

OK, as store is probably negligible, lock-free algorithm means saveing
one interlocked instruction, right?
No.


BTW, do you have some info how really are expensive those atomic
operations?

I have seen numbers from 20 times more expensive to 1000 times more
expensive than non-atomic versions.

On an 866Mhz P3 for an inlined cmpxchg I get 45 nsec w/ lock prefix
and 12 nsec w/o lock prefix. That's not counting a cache line hit.
A normal load is ~3 nsec.

The main benefit from lock-free in a preemptive multi-threaded user
environment is avoiding the overhead of thread suspend/resume when
a thread blocks. 100's of nsec at least. So if lock contention
is a problem and can't be avoided, lock-free is a possible solution.

There's lock-free stuff that doesn't use interlocked instructions or
even memory barriers. I have a hazard pointer load that's only
8 nsec in this case. And some of the proxy stuff will run just
as fast if it's amortized over things like a linked list traversal.

 

[Chris Thomasson]

There's lock-free stuff that doesn't use interlocked instructions or

even memory barriers. I have a hazard pointer load that's only
8 nsec in this case. And some of the proxy stuff will run just
as fast if it's amortized over things like a linked list traversal.

It has to be a very big list, IMO... If the proxy collector acquisition
logic uses a #StoreLoad, the it fu$king wrecks the pipelines and the threads
get off to a bad start... The membar fu$cks thing up real good...

If a reader thread is continually executing searches through the same shared
data-structure, if a #StoreLoad is there, it won't get any use out of its
cache...

 

[Tony]

I don't know about percentages but in applications I write, many are
handled by logging the error. The task in hand is usually aborted but
the task isn't necessarily the whole program. You can't shutdown a
server every time a task fails.

A typical example might be a broken link to a remote server. If the
remote server is down, you log the exception and then subsequently you
might be able to reconnect. Perhaps not every action you do uses that
server anyway.

I wonder if that's a good "use exceptions" scenario rather than just
returning
an error value. I'd probably do the latter. It seems that you'd be checking
for
failure every time you called the connect function and handling that
condition
as appropriate given the context unless a 3rd party library only gave you
the
exception as a way of handling the low-level-detected non-connection. Not
getting a connection seems "too expected" to be an "exception" (what ever
they are! ) with specific handling required dependent on the state of the
program (for instance, does a transaction need to be aborted?).

Not all errors warrant using the C++ exception handling mechanisms.
Somewhere there's a thread about characteristics of errors that classify
them as exceptions or "something else" ("common errors"?).
Characteristics such as: detectability, recoverability, expectability etc.
were considered and discussed. I'm not sure if there was any agreement
on what constitutes an exeption at a high level of categorization. If anyone
knows of such a thread, please post a link to it.

I think it's pretty safe to say that a program will probably require more
than
one EH mechanism to get its job done and C++ exceptions are only one
potential solution for any specific scenario being considered (context
counts).

Tony

 

[Mirek Fidler]

The main benefit from lock-free in a preemptive multi-threaded user
environment is avoiding the overhead of thread suspend/resume when
a thread blocks. 100's of nsec at least. So if lock contention
is a problem and can't be avoided, lock-free is a possible solution.

Win32 has CRITICAL_SECTION variant that spin-locks defined number of
times before suspending the thread. Is not that sort of solution in
certain cases? Is spin-lock considered "lock-free" ?

Mirek

 

[Steven T. Hatton]

Abstract Data Type. Any data type that can contain, and work with,
generic data. That is the definition used in both cases.

That is not correct. See TC++PL(SE) §2.5.4. The "concrete" stack under
discussion would be considered an instance of an ADT in the context in
which I learned the term.

 

[Chris Thomasson]

Win32 has CRITICAL_SECTION variant that spin-locks defined number of
times before suspending the thread. Is not that sort of solution in
certain cases? Is spin-lock considered "lock-free" ?

No. The spinlock is spinning on lock state, not the state you intended to
work on in the first place.

 

[Grizlyk]

Gppd morning.

Six years ago, at the
height (or should I say volume?) of the internet bubble, I had 80+
students per semester in my C++ course. Now I am fortunate to have 15
students per semester. What has changed? I believe that students are
no longer interested in learning C++. They would rather learn .NET
languages or Java (my colleages who teach these courses seem to be very
busy!). I believe it is because these other languages are easier to
learn and/or are perceived to be more relevant today.

I think the next:

In order to write object-oriented programs, we need
1. create classes for your target description
2. support "programming process" and later "program modifications"
(foget the english term)
3. implement of the upper classes hierarhy effective

The last point (implementation) is quite good for C++ and in most
cases, the process is human-independent. It does not matter, in
general, the way of object code compiling - from text files with make
or from pictures from class description etc.

Of course, we need precompiled headers, incremental compiling and so on
to effective compilation, but it is not the most week point of C++ now.
And theoretically, the C++ compiler can be changed not very much in
order to get very different types of code generations.

The first point (create classes), object-oriented designe with the help
of designe-patterns and so on looks like not the C++ matter. C++ must
allow to describe the resulted classes and it can it quite good now.

But the second point (support "programming process") can become C++
matter now. Why? For effective using of classes, effective using of
earlyer development code anyone really need development environment. We
need:
1. to watch all classes of programs, its links, exaples and
descriptions;
2. to watch interface of any class;
3. to open any method of class to edit with greate environment support
(insted of running alogn huge listing of single file or manual file
management);
and many so on.

I really think, it is impossible to write object-oriented programs easy
without development environment.

Noone will write std object-oriented development environment for C++
No development environment - no using of earlyer development code. This
is nature of oo programming.

Some things can get from smalltalk environment, some from other
existing development environment.

People can select ".NET" or "Java" for they looks more attractively for
commercial applications, environment of development is supported by
huge companies for quite short range applications or OSes. They want to
get results "here and now".

 

[Noah Roberts]

That is not correct.

If you say so...

http://en.wikipedia.org/wiki/Abstract_data_type

hth

 

[Mirek Fidler]

No. The spinlock is spinning on lock state, not the state you intended to
work on in the first place.

Ah, I guess I am getting into terminology