473,326 Members | 2,114 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,326 software developers and data experts.

Threading in new C++ standard

Rather than create a new way of doing things:
http://www.open-std.org/jtc1/sc22/wg...008/n2497.html
why not just pick up ACE into the existing standard:
http://www.cse.wustl.edu/~schmidt/ACE.html
the same way that the STL (and subsequently BOOST) have been subsumed?
Since it already runs on zillions of platforms, they have obviously worked
most of the kinks out of the generalized threading and processes idea (along
with many other useful abstractions).

Even more interesting than generalized threading would be generalized
software transactions. The Intel compiler has an experimental version that
does this:
http://softwarecommunity.intel.com/a...s/eng/1460.htm

As we scale to larger and larger numbers of CPUs, the software transaction
model is the one that gains traction. This document is very illuminating in
that regard:
http://internap.dl.sourceforge.net/s..._submitted.pdf


** Posted from http://www.teranews.com **
Jun 27 '08
126 6553

"Markus Elfring" <Ma************@web.dewrote in message
news:68*************@mid.individual.net...
Szabolcs Ferenczi schrieb:
>Finally, let me stress that I am not suggesting that you would make
either Concurrent Pascal, Edison, Ada or OCCAM out of C++. These are
just examples containing useful ideas with respect to concurrent
programming language features.

Do you like the approach "C++CSP2"?
http://www.cs.kent.ac.uk/projects/ofa/c++csp/

Whats this ... Occam in C++?

Actually seems sane... I like it !

regards
Andy Little
Jun 27 '08 #101
On May 3, 10:38 am, "kwikius" <a...@servocomm.freeserve.co.ukwrote:
"Markus Elfring" <Markus.Elfr...@web.dewrote in message

news:68*************@mid.individual.net...
Szabolcs Ferenczi schrieb:
Finally, let me stress that I am not suggesting that you would make
either Concurrent Pascal, Edison, Ada or OCCAM out of C++. These are
just examples containing useful ideas with respect to concurrent
programming language features.
Do you like the approach "C++CSP2"?
http://www.cs.kent.ac.uk/projects/ofa/c++csp/

Whats this ... Occam in C++?

Actually seems sane... I like it !

regards
Andy Little
However, this is clearly not a shared memory approach. It may well
make lots of sense, but it's not what we set out to standardize. It's
also not what most applications tend to use. Or what that cache
coherence hardware in your PC was designed for. Some of the other
approaches discussed in this thread also seem to border on distributed
memory approaches, and similar comments may apply.

Hans

Jun 27 '08 #102
On May 4, 1:59*am, "Boehm, Hans" <hans.bo...@hp.comwrote:
On May 3, 10:38 am, "kwikius" <a...@servocomm.freeserve.co.ukwrote:
"Markus Elfring" <Markus.Elfr...@web.dewrote in message
news:68*************@mid.individual.net...
Szabolcs Ferenczi schrieb:
>Finally, let me stress that I am not suggesting that you would make
>either Concurrent Pascal, Edison, Ada or OCCAM out of C++. These are
>just examples containing useful ideas with respect to concurrent
>programming language features.
Do you like the approach "C++CSP2"?
>http://www.cs.kent.ac.uk/projects/ofa/c++csp/
Whats this ... Occam in C++?
Actually seems sane... I like it !
regards
Andy Little

However, this is clearly not a shared memory approach. *It may well
make lots of sense, but it's not what we set out to standardize. *It's
also not what most applications tend to use. *Or what that cache
coherence hardware in your PC was designed for. *Some of the other
approaches discussed in this thread also seem to border on distributed
memory approaches, and similar comments may apply.

Hans
Jun 27 '08 #103

"Boehm, Hans" <ha********@hp.comwrote in message
news:13**********************************@f24g2000 prh.googlegroups.com...
On May 3, 10:38 am, "kwikius" <a...@servocomm.freeserve.co.ukwrote:
>"Markus Elfring" <Markus.Elfr...@web.dewrote in message

news:68*************@mid.individual.net...
Szabolcs Ferenczi schrieb:
Finally, let me stress that I am not suggesting that you would make
either Concurrent Pascal, Edison, Ada or OCCAM out of C++. These are
just examples containing useful ideas with respect to concurrent
programming language features.
Do you like the approach "C++CSP2"?
http://www.cs.kent.ac.uk/projects/ofa/c++csp/

Whats this ... Occam in C++?

Actually seems sane... I like it !

regards
Andy Little

However, this is clearly not a shared memory approach. It may well
make lots of sense, but it's not what we set out to standardize. It's
also not what most applications tend to use. Or what that cache
coherence hardware in your PC was designed for. Some of the other
approaches discussed in this thread also seem to border on distributed
memory approaches, and similar comments may apply.
Please don't attach any weight to my comments about concurrency. I don't use
threads except in tiny test apps just to experiment.

My understanding of the status quo re concurrency in C++0x is that you are
concentrating on low level primitives and obviously the major concern is
whether you have got those right to build higher level constructs.

FWIW Here are 2 areas where I can see that concurrency would be useful for
me.

The first is in file output. When the user presses "save" I create a process
to perform the job. Its a lot easier Not to create a process and just show a
wait cursor, though not ideal for the user. OTOH If I create a separate
process I need to figure out some strategy for what happens if something
goes wrong, and how I get that reported back at some unknown time.

The other area is in processing vectors(math vectors of compile time fixed
size rather than std::vector). Theoretically multiplication of a vector by a
scalar or dot product could be done in parallel, and ideally expressible
somehow in the language I think rather than requiring assembler.

The following is some quick attempt at a language extension to express sum
and dot on a vector FWIW:

regards
Andy Little

// vector sum

// even size vector add every element to next recursively
template <int Size>
{where Size % 2 == 0 }
double
sum(Vect<Sizev)
{
static const int N = Size/2;
vect<Nin;
// some notation to say do these calcs in parallel
parallel[N]:n{
in[n] = v[2*n] + v[2*n+1];
}
// recurse until size of vector is 1
return sum(in);
}

// odd size vector
template <int Size>
{where ( Size % 2 ==1 ) && ( Size 1 ) }
double
sum(Vect<Sizev)
{
return v[0] + sum(vect_view<1,Size>(v));
}

// size 1 vector
template <int Size>
double
{where Size ==1 }
sum(Vect<Sizev)
{
return v[0];
}

//vector dot
template <int Size>
dot_product( vect<SizevL, vect<Sizevr )
{
vect<Sizein;
// do mux in parallel
parallel[Size]:n {
in[n] = vl[n] * Vr[n];
}
return sum(in);
}
Jun 27 '08 #104
On May 4, 1:59*am, "Boehm, Hans" <hans.bo...@hp.comwrote:
On May 3, 10:38 am, "kwikius" <a...@servocomm.freeserve.co.ukwrote:
"Markus Elfring" <Markus.Elfr...@web.dewrote in message
news:68*************@mid.individual.net...
Szabolcs Ferenczi schrieb:
>Finally, let me stress that I am not suggesting that you would make
>either Concurrent Pascal, Edison, Ada or OCCAM out of C++. These are
>just examples containing useful ideas with respect to concurrent
>programming language features.
Do you like the approach "C++CSP2"?
>http://www.cs.kent.ac.uk/projects/ofa/c++csp/
Whats this ... Occam in C++?
Actually seems sane... I like it !
Pleas ignore the previous post, just pushed the button by accident.
However, this is clearly not a shared memory approach.
That is right. They clearly missed the point here. It frequently
happens when people are not disciplined enough.

What I was discussing in the original post where they picked up a
keyword was the following: I think that at the language level most
probably an adapted form of Dijkstra's Guarded Commands could be used
to cope with non-determinism.

I have just given some examples that Guarded Commands has been adapted
in some languages and language proposals already:

1) for shared memory communication in the language proposal
Distributed Processes (DP) or in the Edison language; and

2) for message-based communication in the Communicating Sequential
Processes (CSP) of which a language realisation is the OCCAM language.

The lad just picked up a keyword. It is not the first time it happens.
Though, I clearly indicated that the mention of these keywords is just
illustration and this text is even copied here.
>*It may well
make lots of sense, but it's not what we set out to standardize. *It's
also not what most applications tend to use.
For standardisation, probably it is out of question. However, if you
consider the needs of a modern concurrent programming language, it
should probably deal with mixed architectures as well, i.e. mixed
shared memory and distributed memory ones. The Guarded commands can be
adapted to both architectures since the main issue there is that the
language level construction matches with the non-determinism that
arises in any co-operating process architecture.

I guess that mixed architectures are far away from the low level
library-based standardisation efforts in C++0x, however. Lads might
pick up keywords again, though.

Best Regards,
Szabolcs
Jun 27 '08 #105
On 2008-05-04 11:07, kwikius wrote:
The other area is in processing vectors(math vectors of compile time fixed
size rather than std::vector). Theoretically multiplication of a vector by a
scalar or dot product could be done in parallel, and ideally expressible
somehow in the language I think rather than requiring assembler.
You might want to check out OpenMP, it makes it very easy to parallelise
things like for-loops. The hard part if finding what to parallelise,
i.e. the loop in the dot-product or the calculation of the dot-product
for a lot of vectors.

--
Erik Wikström
Jun 27 '08 #106

"kwikius" <an**@servocomm.freeserve.co.ukwrote in message
news:48**********@mk-nntp-2.news.uk.tiscali.com...

<...>
The following is some quick attempt at a language extension to express sum
and dot on a vector FWIW:
<snip pseudo stuff>

Below is a version which is standard C++... no parallel, N in app can be
easily modified for diff size arrays.

Its interesting to see how the asm changes as N gets bigger:

Asm produced by VC8 with optimisation at end, shows how near it is to being
able to parallelise.

regards
Andy Little

//sfinae

template <bool C, typename T = void>

struct where_{

typedef T type;

};

template <typename T>

struct where_<false,T>{};

// fixed size vect

template <int N>

struct vect

{

double elements[N];

vect(double (& ar)[N]){

for (int i = 0; i < N; ++i){

elements[i] = ar[i];

}

}

vect(){}

static const int size = N;

double const & operator [] (int n) const

{

return elements[n];

}

double & operator [] (int n)

{

return elements[n];

}

vect & operator = (vect const & in)

{

for ( int i = 0; i < N ; ++i){

elements[i] = in[i];

}

}

};

template <typename Vect,int Offset>

struct vect_view{

Vect const & v;

vect_view(Vect const & in) : v(in){}

double const & operator [] (int n)const

{

return v[n + Offset];

}

static const int size = Vect::size - Offset;

vect_view & operator = (vect_view const & in)

{

for (int i = 0; i < N ; ++i){

elements[i] = in[i];

}

}

};

template <int N, typename Where = void>

struct sum_impl;

template <int N>

struct sum_impl<N, typename where_<(N >= 2) && ((N %2) ==0) >::type >

{

template <typename T>

double operator()(T const & in)const

{

vect<N/2out;

for (int i = 0; i < N /2 ; ++i){

out[i] = in[i*2] + in[i*2 +1];

}

sum_impl<N/2s;

return s(out);

}

};

template <int N>

struct sum_impl<N, typename where_<(N 2) && ((N %2) == 1)>::type>

{

template <typename T>

double operator()(T const & in)const

{

sum_impl<N-1s;

return in[0] + s(vect_view<T,1>(in) );

}

};

template <int N>

struct sum_impl<N, typename where_<(N ==1)>::type>

{

template <typename T>

double operator()(T const & in)const

{

return in[0];

}

};

template <typename V>

double sum( V const & v)

{

sum_impl<V::sizes;

return s(v);

}

template <typename V>

double dot( V const & lhs, V const & rhs)

{

vect<V::sizev;

for (int i = 0; i < V::size;++i){

v[i] = lhs[i] * rhs[i];

}

return sum(v);

}

///-----------------------------

#include <iostream>

int main()

{

static const int n = 4;

double ar[n] ;

std::cout << "input " << n << " doubles\n";

for ( int i = 0; i < n; ++i){

std::cin >ar[i];

}

std::cout << "thankyou\n";

vect<nvv(ar);

double r = dot(vv,vv);

std::cout << r <<'\n';

}

// asm for n = 4 in VC8

; 136 : double r = dot(vv,vv);

fld QWORD PTR _ar$[esp+72]

fmul ST(0), ST(0)

; 137 : std::cout << r <<'\n';

mov ecx, DWORD PTR
__imp_?cout@std@@3V?$basic_ostream@DU?$char_traits @D@std@@@1@A

fld QWORD PTR _ar$[esp+80]

fmul ST(0), ST(0)

fld QWORD PTR _ar$[esp+88]

fmul ST(0), ST(0)

fld QWORD PTR _ar$[esp+96]

fmul ST(0), ST(0)

fxch ST(2)

faddp ST(3), ST(0)

faddp ST(1), ST(0)

faddp ST(1), ST(0)

fstp QWORD PTR [esp]

call DWORD PTR
__imp_??6?$basic_ostream@DU?$char_traits@D@std@@@s td@@QAEAAV01@N@Z
Jun 27 '08 #107

"Erik Wikström" <Er***********@telia.comwrote in message
news:UP*****************@newsb.telia.net...
On 2008-05-04 11:07, kwikius wrote:
>The other area is in processing vectors(math vectors of compile time
fixed
size rather than std::vector). Theoretically multiplication of a vector
by a
scalar or dot product could be done in parallel, and ideally expressible
somehow in the language I think rather than requiring assembler.

You might want to check out OpenMP, it makes it very easy to parallelise
things like for-loops.
....
The hard part if finding what to parallelise,
i.e. the loop in the dot-product or the calculation of the dot-product
for a lot of vectors.
Both .... :-)

regards
Andy Little
Jun 27 '08 #108
On May 3, 10:57 am, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
and I document that link-time optimization level should be turned down, or
off... Oh well.

Link-time optimization can increase performance by 10-20%. And it's on
by default in release build of MSVC...

Btw, Joe Seigh in atomic-ptr uses following:
#define fence() __asm__ __volatile__ ("" : : : "memory")
#define smrnull(hptr) \
do { \
fence(); \
atomic_store(&hptr[0], 0); \
atomic_store(&hptr[1], 0); \
} while (0)
What do you think?
From linux kernel (include/linux/compiler-gcc.h):

/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

This thing is prevalent for suppressing compiler optimizations...

Dmitriy V'jukov
Jun 27 '08 #109
"Dmitriy V'jukov" <dv*****@gmail.comwrote in message
news:08**********************************@i36g2000 prf.googlegroups.com...
On May 3, 10:57 am, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
and I document that link-time optimization level should be turned down,
or
off... Oh well.

Link-time optimization can increase performance by 10-20%. And it's on
by default in release build of MSVC...

Btw, Joe Seigh in atomic-ptr uses following:
#define fence() __asm__ __volatile__ ("" : : : "memory")
#define smrnull(hptr) \
do { \
fence(); \
atomic_store(&hptr[0], 0); \
atomic_store(&hptr[1], 0); \
} while (0)
What do you think?

From linux kernel (include/linux/compiler-gcc.h):

/* Optimization barrier */
/* The "volatile" is due to gcc bugs */
#define barrier() __asm__ __volatile__("": : :"memory")

This thing is prevalent for suppressing compiler optimizations...
Right. I use that when the build detects that its compiling under something
that is compatible with GNU C; _ReadWriteBarrier() on VC++, and external
function call for everything else.

Jun 27 '08 #110
On May 2, 1:10 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
>
There are synchronization algorithms where compiler ordering affects
exactly threads.

Asymmetric reader-writer mutex:http://groups.google.ru/group/comp.p...browse_frm/thr...
I don't think this is otherwise implementable in standard C++, without
asynchronous signals, right? You somehow need to interrupt each
potential reader to get control. That sounds like it's logically at
least an asynchronous signal? I agree that compiler fences are useful
in such cases.

In SMR+RCU they looks like this:

// pseudo-code
void* smr_rcu_acquire_reference
(void** shared_object, void** hazard_pointer)
{
for (;;)
{
void* object = *shared_object;
*hazard_pointer = object;
compiler_store_load_fence();
void* object2 = *shared_object;
if (object == object2)
{
compiler_acquire_fence();
return object;
}
}

}
This presumably makes sense only if you do something analogous to
interrupting this thread, or checking to make sure that the OS already
did so for you?
I think that Sequence Lock (SeqLock):http://en.wikipedia.org/wiki/Seqlock
must be implemented this way:

bool sequence_lock_rdunlock(seqlock* lock, int prev_seq)
{
int seq = lock->seq.load(std::memory_order_load_release_wrt_loads );
return seq == prev_seq;

}

On x86 memory_order_load_release_wrt_loads is no-op (plain load). But
if I use 'next stronger ordering constraint', i.e.
memory_model_acq_rel, then it will be locked rmw operation or mfence
instruction. I think in most C++ implementations it will be locked rmw
operation. And locked rmw operation means ownership of cache-line.
This basically kills the whole idea of SeqLock...
We have a difference of perspective here. This sort of "sequence
lock" is strange, in that the reads in the "critical section"
participate in data races, even with the "locks" in place. The C++0x
WP gives undefined semantics to this sort of data race; the hardware
is allowed to catch fire if one occurs. (Not a recommended
implementation technique, but it both ensures that careful data race
detectors can avoid false positives, and it allows compilers to assume
that ordinary data cannot change asynchronously. There are some cases
in which that assumption can induce a crash, not just a bad value, if
it's falsified.)

Thus

(a) I wouldn't call this a lock.
(b) If you want to use it, the data accessed inside the lock should
still be declared atomic.

If you do this, and specify at least memory_order_acquire everywhere,
except possibly in rdunlock, I think you get the right semantics.
And on X86, you get no fence overhead. It's not really clear to me
that you can do better without requiring that compilers obey some
safety constraints in the presence of data races. The reasons not to
do that are:

1) You're invalidating a fairly pervasive assumption made by curent
compilers, though the assumption rarely seems to matter in practice.
But removing all uses of that assumption is not likely to be easy.

2) We don't really know how to write down very good constraints. The
Java memory model is probably the best attempt, but even it still
appears to have some subtle and unintended optimization consequences
(see http://www.inf.ed.ac.uk/publications/report/1121.html). And it's
complicated for largely this reason. (Java unfortunately can't dodge
the issue like we did.)

Hans

Jun 27 '08 #111
"Chris Thomasson" <cr*****@comcast.netwrote in message
news:Ha******************************@comcast.com. ..
>
"Dmitriy V'jukov" <dv*****@gmail.comwrote in message
news:d9**********************************@34g2000h sf.googlegroups.com...
[...]
>There are synchronization algorithms where compiler ordering affects
exactly threads.
[...]
Unless C++ provides a 'rcu_synchronize()' type function, well,
passive sync-epoch detection.
^^^^^^^^^^^^^^^

insert the word '__portable__' in front of the word 'passive'.

[...]

Jun 27 '08 #112
"Boehm, Hans" <ha********@hp.comwrote in message
news:f2**********************************@p39g2000 prm.googlegroups.com...
On May 2, 1:10 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
>>
There are synchronization algorithms where compiler ordering affects
exactly threads.

Asymmetric reader-writer
mutex:http://groups.google.ru/group/comp.p...browse_frm/thr...
I don't think this is otherwise implementable in standard C++, without
asynchronous signals, right? You somehow need to interrupt each
potential reader to get control. That sounds like it's logically at
least an asynchronous signal?
You can use asynchronous signals to ensure that readers threads have
executed a memory barrier:

http://groups.google.com/group/comp....45d3e17806ccfe
Dmitriy moved basically _all_ the synchronization responsibilities over to
the writer. It needs to ensure that the readers have executed membars. There
are several techniques with signals being one of them..

I agree that compiler fences are useful in such cases.
Indeed they are.

>In SMR+RCU they looks like this:

// pseudo-code
void* smr_rcu_acquire_reference
(void** shared_object, void** hazard_pointer)
{
for (;;)
{
void* object = *shared_object;
*hazard_pointer = object;
compiler_store_load_fence();
void* object2 = *shared_object;
if (object == object2)
{
compiler_acquire_fence();
return object;
}
}

}
This presumably makes sense only if you do something analogous to
interrupting this thread, or checking to make sure that the OS already
did so for you?
No thread interruption has to be involved. The only requirement is the each
SMR thread must periodically/episodically execute something that is
analogous to a store/load memory barrier. This can range from
context-switching, system calls, signals, whatever. A detection/polling
method is used to determine when each SMR thread has executed a
synchronization operation (e.g, the membar). Efficient solutions to this are
highly platform specific.

>I think that Sequence Lock (SeqLock):http://en.wikipedia.org/wiki/Seqlock
must be implemented this way:

bool sequence_lock_rdunlock(seqlock* lock, int prev_seq)
{
int seq = lock->seq.load(std::memory_order_load_release_wrt_loads );
return seq == prev_seq;

}

On x86 memory_order_load_release_wrt_loads is no-op (plain load). But
if I use 'next stronger ordering constraint', i.e.
memory_model_acq_rel, then it will be locked rmw operation or mfence
instruction. I think in most C++ implementations it will be locked rmw
operation. And locked rmw operation means ownership of cache-line.
This basically kills the whole idea of SeqLock...
We have a difference of perspective here. This sort of "sequence
lock" is strange, in that the reads in the "critical section"
participate in data races, even with the "locks" in place.
IMHO, it looks like a form of STM. Readers use version numbers, and Writers
are synchronized and always end of up adding the value of 2 to the version.
Any odd number is inconsistent data. Reads can suffer from STM induced
livelock during sustained periods of write activity...


[...]

Jun 27 '08 #113
On May 10, 1:31 am, "Boehm, Hans" <hans.bo...@hp.comwrote:
On May 2, 1:10 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
There are synchronization algorithms where compiler ordering affects
exactly threads.
Asymmetric reader-writer mutex:http://groups.google.ru/group/comp.p...browse_frm/thr...

I don't think this is otherwise implementable in standard C++, without
asynchronous signals, right?

Right. But the question is whether one have to:
(1) implement a piece of OS dependant code in C/C++
or
(2) implement a piece of OS dependant code in C/C++ + implement own
atomics library in assembly for every compiler x every hardware
platform

And I take a look at atomic_ops... it's very... encumbered... I don't
want to implement something similar... really.

Well, I've read Paul McKenney's n2237 "A simple and efficient memory
model for weakly-ordered architectures":
http://www.open-std.org/jtc1/sc22/wg...2007/n2237.pdf

He conclides:
"This is a prioritized list of differences of this model versus ISOMM:
[...]
5. Define a mechanism to allow ordering of atomic operations without
introducing any hardware primitives."

At least you are aware (not surprisingly). So decision will be well-
weighed (not surprisingly too).
In SMR+RCU they looks like this:
// pseudo-code
void* smr_rcu_acquire_reference
(void** shared_object, void** hazard_pointer)
{
for (;;)
{
void* object = *shared_object;
*hazard_pointer = object;
compiler_store_load_fence();
void* object2 = *shared_object;
if (object == object2)
{
compiler_acquire_fence();
return object;
}
}
}

This presumably makes sense only if you do something analogous to
interrupting this thread, or checking to make sure that the OS already
did so for you?

Yes.

I think that Sequence Lock (SeqLock):http://en.wikipedia.org/wiki/Seqlock
must be implemented this way:
bool sequence_lock_rdunlock(seqlock* lock, int prev_seq)
{
int seq = lock->seq.load(std::memory_order_load_release_wrt_loads );
return seq == prev_seq;
}
On x86 memory_order_load_release_wrt_loads is no-op (plain load). But
if I use 'next stronger ordering constraint', i.e.
memory_model_acq_rel, then it will be locked rmw operation or mfence
instruction. I think in most C++ implementations it will be locked rmw
operation. And locked rmw operation means ownership of cache-line.
This basically kills the whole idea of SeqLock...

We have a difference of perspective here. This sort of "sequence
lock" is strange, in that the reads in the "critical section"
participate in data races, even with the "locks" in place. The C++0x
WP gives undefined semantics to this sort of data race; the hardware
is allowed to catch fire if one occurs. (Not a recommended
implementation technique, but it both ensures that careful data race
detectors can avoid false positives, and it allows compilers to assume
that ordinary data cannot change asynchronously. There are some cases
in which that assumption can induce a crash, not just a bad value, if
it's falsified.)

C/C++ are famous and valuable for the ability to shoot yourself in the
foot if you really want to (or just know what you are doing).

For example, RCU in Linux kernel makes following assumption "execution
of full memory barrier by every processor == execution of full memory
barrier by every thread". Right?
It's incorrect assumption in the context of current C++0x. So
according to current C++0x it's One Big Data Race, so all machines
running linux will start catching fire in 2009...

I'm going to use above 'sequence lock' in the following context:

POD_datatype obj;
int seq = 0;
do
{
seq = sequence_lock_rdlock(&g_lock);
// only load data, no usage before consistency validation
memcpy(&obj, g_obj, sizeof(obj));
}
while (false == sequence_lock_rdunlock(&g_lock, seq));
use(obj);

I think that it will be sufficiently working and sufficiently
portable. No matter what races it involves according to C++0x. Like
RCU.
I am not saying that it's a good line of reasoning in common case.
Dmitriy V'jukov
Jun 27 '08 #114
On May 14, 5:02 pm, "Dmitriy V'jukov" <dvyu...@gmail.comwrote:
...
C/C++ are famous and valuable for the ability to shoot yourself in the
foot if you really want to (or just know what you are doing).

For example, RCU in Linux kernel makes following assumption "execution
of full memory barrier by every processor == execution of full memory
barrier by every thread". Right?
It's incorrect assumption in the context of current C++0x. So
according to current C++0x it's One Big Data Race, so all machines
running linux will start catching fire in 2009...
I think it's safe to say that no OS kernel has ever been a strictly-
conforming C++ (or C) program. It will always rely on specific
platform knowledge that can't be generally guaranteed by the language
standard. The C++ standard give you no way to tell which processor
you're running on, so this sort of thing will always be beyond the
standard,
as I believe it should be. That doesn't mean things will break. It
just means that we will continue to not guarantee that this sort of
thing is correct in portable code.

You do need correct handling of data dependencies to ensure that RCU
works. That currently works because the kernel relies on dependence-
based ordering only in sufficiently simple cases, in which the
compiler isn't tempted to break anything. That restriction is hard to
express in a standard. Which is why it's taking a while to decide
precisely what we want to do here. We may end up substantially
improving matters.
>
I'm going to use above 'sequence lock' in the following context:

POD_datatype obj;
int seq = 0;
do
{
seq = sequence_lock_rdlock(&g_lock);
// only load data, no usage before consistency validation
memcpy(&obj, g_obj, sizeof(obj));}

while (false == sequence_lock_rdunlock(&g_lock, seq));
use(obj);

I think that it will be sufficiently working and sufficiently
portable. No matter what races it involves according to C++0x. Like
RCU.
I am not saying that it's a good line of reasoning in common case.
The problem is what happens if, inside the sequence_rdlock, someone
writes

x = global_uint;
if (x < 3) {
...
switch (global_uint) {
case 0: ...
case 1: ...
case 2: ...
}
}

where all the ... sections only read global data, the compiler
implements the switch with a branch table, and eliminates the bounds
check because it knows global_uint < 3? The code inside the sequence
lock still basically only reads global data, but the result is clearly
broken. Am I not allowed to perform conditional and switch statements
inside sequence locks? How would the standard express that? Or do I
want to check all compilers (and possibly rewrite some textbooks) to
make sure that such optimizations don't occur?

Or what happens if I run this code through some future data race
detector, as I probably should?

Is it worth trying to handle all of these things somehow to make it
more convenient to write such relatively esoteric code?

Hans
>
Dmitriy V'jukov
Jun 27 '08 #115
On 2008-05-22 12:32:05 -0400, Szabolcs Ferenczi
<sz***************@gmail.comsaid:
On May 1, 8:07Â*am, Owen Jacobson <angrybald...@gmail.comwrote:
>On Apr 25, 5:04Â*pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:
>>On Apr 25, 11:57Â*am, James Kanze <james.ka...@gmail.comwrote:
>>>...
No. Â*Several people have pointed out several times where the
language addresses concurrency issues.
>>Oh yes, you are one of them who continously keep saying that C++0x
adresses concurrency issues at the language level but who fail to put
here just a single language element for it.

If the only "language element" your world-view will admit is a new
syntactic construct, then you're right and the new C++ standard does
not contain any language elements to support threading.

It is at least honest of you to admit that "the new C++ standard does
not contain any language elements to support threading."
Good for you! You've actually retained the words that you're responding
to, making it easy for anyone reading your message to see that you've
misrepresented what they say.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Jun 27 '08 #116
On May 22, 6:49*pm, Pete Becker <p...@versatilecoding.comwrote:
Good for you! You've actually retained the words that you're responding
to, making it easy for anyone reading your message to see that you've
misrepresented what they say.
Try to read it carefully, you might benefit from it. If you are
willing to learn, of course. Otherwise just keep trolling.

Best Regards,
Szabolcs
Jun 27 '08 #117
On 2008-05-22 12:57:21 -0400, Szabolcs Ferenczi
<sz***************@gmail.comsaid:
On May 22, 6:49Â*pm, Pete Becker <p...@versatilecoding.comwrote:
>Good for you! You've actually retained the words that you're responding
to, making it easy for anyone reading your message to see that you've
misrepresented what they say.

Try to read it carefully, you might benefit from it. If you are
willing to learn, of course. Otherwise just keep trolling.
Now you're back to taking things out of context. I guess I was too optimistic.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Jun 27 '08 #118
On May 22, 7:05*pm, Pete Becker <p...@versatilecoding.comwrote:
On 2008-05-22 12:57:21 -0400, Szabolcs Ferenczi
<szabolcs.feren...@gmail.comsaid:
Try to read it carefully, you might benefit from it. If you are
willing to learn, of course. Otherwise just keep trolling.

Now you're back to taking things out of context. I guess I was too optimistic.
If you are incapable to contribute to the professional issues, please
retain from trolling.

Thanks,
Szabolcs
Jun 27 '08 #119

"Szabolcs Ferenczi" <sz***************@gmail.comwrote in message
news:40**********************************@79g2000h sk.googlegroups.com...
The memory is orthogonal to a high level programming language. A
programming language deals with abstractions called variables which in
turn are mapped onto the physical memory. But memory does not appear
directly at the language level hence there is no need for any memory
model at the language level.
You're in the wrong newsgroup... wrong language. The probability is zero
that C++ will ditch its machine model.
The current situation AFAICS is that concurrency is being bolted on
delicately to the old dog, with a blowtorch.

You sound to me like the sort of person that would me much more a home with
a functional language or designing your own language.

regards
Andy Little



Jun 27 '08 #120
On 2008-05-22 13:11:26 -0400, Szabolcs Ferenczi
<sz***************@gmail.comsaid:
On May 22, 7:05Â*pm, Pete Becker <p...@versatilecoding.comwrote:
>On 2008-05-22 12:57:21 -0400, Szabolcs Ferenczi
<szabolcs.feren...@gmail.comsaid:
>>Try to read it carefully, you might benefit from it. If you are
willing to learn, of course. Otherwise just keep trolling.

Now you're back to taking things out of context. I guess I was too optimis
tic.

If you are incapable to contribute to the professional issues, please
retain from trolling.
You snipped relevant context again. Sigh.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Jun 27 '08 #121
On May 22, 8:52*pm, Pete Becker <p...@versatilecoding.comwrote:
You snipped relevant context again. Sigh.
You must decide at last what you want. First your problem was that I
left there the part I have reflected. Now you claim I removed
something from your valuable troll.

I ask you again: Please stop trolling.

If you have some professional argument, then share it with us,
otherwise please stop trolling.

Best Regards,
Szabolcs
Jun 27 '08 #122
Szabolcs Ferenczi wrote:
On May 22, 6:49 pm, Pete Becker <p...@versatilecoding.comwrote:
>Good for you! You've actually retained the words that you're responding
to, making it easy for anyone reading your message to see that you've
misrepresented what they say.

Try to read it carefully, you might benefit from it. If you are
willing to learn, of course. Otherwise just keep trolling.
You are aware that Pete is one of the more respected language gurus
around, and that he sits on the ISO Committee (I think)?
Jun 27 '08 #123
On May 23, 2:53*am, red floyd <no.s...@here.dudewrote:
Szabolcs Ferenczi wrote:
On May 22, 6:49 pm, Pete Becker <p...@versatilecoding.comwrote:
Good for you! You've actually retained the words that you're responding
to, making it easy for anyone reading your message to see that you've
misrepresented what they say.
Try to read it carefully, you might benefit from it. If you are
willing to learn, of course. Otherwise just keep trolling.

You are aware that Pete is one of the more respected language gurus
around, and that he sits on the ISO Committee (I think)?
Sure. Does it entitle him to stuck up?

No matter what he thinks about himself, he should consider the ancient
saying: Hic Rhodus hic salta---which very well applies to him here.

Also see the fable here:
http://groups.google.com/group/comp....b988ca79770d11

So simple is it.

Best Regards,
Szabolcs
Jun 27 '08 #124
On May 23, 2:53 am, red floyd <no.s...@here.dudewrote:
Szabolcs Ferenczi wrote:
On May 22, 6:49 pm, Pete Becker <p...@versatilecoding.comwrote:
Good for you! You've actually retained the words that
you're responding to, making it easy for anyone reading
your message to see that you've misrepresented what they
say.
Try to read it carefully, you might benefit from it. If you
are willing to learn, of course. Otherwise just keep
trolling.
You are aware that Pete is one of the more respected language
gurus around, and that he sits on the ISO Committee (I think)?
He's the project editor, which means that he's the person who
actually writes the final wording of the standard (or integrates
the wording into the standard).

In other postings (threads, groups), Szabolcs has also treated
Hans Boehm and David Butenhof as idiots, so Pete's in good
company. According to Szabolcs, Szabolcs is the only expert,
and all of the recognized experts are idiots, because they don't
bow down to him.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Jun 27 '08 #125
On May 23, 10:35*am, James Kanze <james.ka...@gmail.comwrote:
In other postings (threads, groups), Szabolcs has also treated
Hans Boehm and David Butenhof as idiots, so Pete's in good
company. *
That is a clear lie.

You cannot prove it as well as you cannot do your homework because you
have lied about your `professional work' too.

The truth is that I could carry on some good level professional
conversations here with Hans Boehm, and on the other hand, Butenhof
really showed great arrogance and enormous hybris in other discussion
threads.

Please stop telling lies even if you are notorious in it.

Thanks for your efforts,
Szabolcs
Jun 27 '08 #126
Szabolcs Ferenczi wrote:
On May 23, 10:35 am, James Kanze <james.ka...@gmail.comwrote:
>In other postings (threads, groups), Szabolcs has also treated
Hans Boehm and David Butenhof as idiots, so Pete's in good
company.

That is a clear lie.

You cannot prove it as well as you cannot do your homework because you
have lied about your `professional work' too.

The truth is that I could carry on some good level professional
conversations here with Hans Boehm, and on the other hand, Butenhof
really showed great arrogance and enormous hybris in other discussion
threads.

Please stop telling lies even if you are notorious in it.

*PLONK*
Jun 27 '08 #127

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

22
by: Jorge Godoy | last post by:
Hi! I must have been searching in the wrong places or with the wrong keywords but I couldn't find out how to implement something such as what is done by the threading module on Windows (95, 98...
17
by: Andrae Muys | last post by:
Found myself needing serialised access to a shared generator from multiple threads. Came up with the following def serialise(gen): lock = threading.Lock() while 1: lock.acquire() try: next...
4
by: Joe Wong | last post by:
Hi, Is there any way to increase/decrease a thread priority in Python? Best regards, -- Wong
77
by: Jon Skeet [C# MVP] | last post by:
Please excuse the cross-post - I'm pretty sure I've had interest in the article on all the groups this is posted to. I've finally managed to finish my article on multi-threading - at least for...
5
by: Roshan | last post by:
This is regarding the article titled "C++ & Double-Checked Locking" by Scott Meyers and Andrei in DDJ July 2004 issue. I think the reasoning in this article is fundamentally flawed due the...
4
by: Lionel van den Berg | last post by:
Hi all, I'm just wondering what's the best option for threading in C++? I've used pthreads and forking in C (the latter is not appropriate for my situation now). All I want to do is run a...
2
by: Juuso Hukkanen | last post by:
I need a list of multithreading unsafe C (C99) functions/features. comp.programming.threads provided an initial list of C:ish functions, with following ANSI C functions: asctime, gmtime,...
9
by: cgwalters | last post by:
Hi, I've recently been working on an application which does quite a bit of searching through large data structures and string matching, and I was thinking that it would help to put some of this...
1
by: Seun Osewa | last post by:
Hello, I've tried to run several threading examples in Python 2.5.1 (with Stackless) For example: import threading theVar = 1 class MyThread ( threading.Thread ):
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.