comp.programming.threads Google Group

Re: POD function static initialization from function return, thread safe?

2008-10-06T17:42:02Z

Safe both inside and outside a function; initialized at compile time.
If keeps that value I'd insert a "const" there just to make that point
to myself, unless I need a non-const* pointer to it.
Or pthread_once() with a pthread_once_t variable. That's what they are
for.

Re: POD function static initialization from function return, thread safe?

2008-10-06T13:19:19Z

POD assignment in general is not atomic unless
sizeof(POD)==sizeof(int), even on platforms where plain ops on an int
are atomic (e.g. x86).
The lack of atomicity of the assignment is the only problem with
static initialization and threads.
This is not guaranteed to be safe prior to C++0x. If multiple threads

Re: POD function static initialization from function return, thread safe?

2008-10-06T13:13:37Z

Wrong. Initialization of a POD struct with an aggregate initializer
consisting only of constant expressions is static initialization and
must happen before the execution of the program begins.
This too is safe.
Totally agree here. Dynamic initialization is not safe.
Agree that this is still not safe: it's still dynamic initialization.

Re: POD function static initialization from function return, thread safe?

2008-10-06T11:57:25Z

Simply make your code conditionally compile. Define a preprocessor
value that triggers this optimization. Ensure it is defined only on
platforms where this is known to be safe. You may wish to issue a
warning if you're running on a platform where it is not know to be
safe. The warning should get someone to check the platform.

Re: supporting header-less blocks in memory allocators...

2008-10-06T07:02:32Z

This should help:
void operator delete [](void* mem, std::size_t size) throw()
{
size = size * *(size_t*)mem + sizeof(size_t);
custom_allocator::deallocate(m em, size);
Dmitriy V'jukov

Re: want to kick the tires on a new multithreading tool?

2008-10-05T01:44:15Z

[...]
Why switch from TBB?

Re: POD function static initialization from function return, thread safe?

2008-10-05T01:34:18Z

Yes; POSIX compliant compiler along with a POSIX library is the only way to
ensure correctness.
impl detail indeed.

POD function static initialization from function return, thread safe?

2008-10-04T21:50:23Z

I know from previous posts on this list that function static
initialization is not thread safe. But in the case of initializing
plain old data (POD) from a re-entrant function that will return the
same value every time, the race condition appears to be
inconsequential. The assumption appears to be that POD assignment is

Re: POD function static initialization from function return, thread safe?

2008-10-04T13:15:57Z

It's the matter of the compiler vendor to ensure that this works as
intended. Furthermore, as long as a variable has global static storage,
it might be initialized "at compile time" by placing the right data into
the data section of the executable, and at loading time, the problem
does not exist.

Re: POD function static initialization from function return, thread safe?

2008-10-04T11:51:49Z

[...]
do you think that:
PTHREAD_MUTEX_INITIALIZER
is busted?

Re: POD function static initialization from function return, thread safe?

2008-10-04T09:02:01Z

All I know of. For example,
struct foo {
int a,b;
static struct foo f = {1,2};
is a POD initialization, and if two threads run into this line of code,
it may happen that thread A initializes f.b while thread B is already
using f.b for something else, so no, this is definitely not safe. Even
if you return a copy of f from a function:

Re: supporting header-less blocks in memory allocators...

2008-10-04T05:41:41Z

Humm... What do you think about the following technique; here is a full
example program:
______________________________ ______________________________ _____________
static void*
thread_alloc_4(size_t size) {
void* const mem = malloc(size);
printf("thread_alloc_4(%lu) -> %p\n",
(unsigned long int)size, mem);

Re: supporting header-less blocks in memory allocators...

2008-10-04T05:19:59Z

Also, I don't think that your `object_t' class needs to be a template at
all. Here is test code:
______________________________ ______________________________ _____
struct custom_allocator {
static void* allocate(std::size_t size)
throw(std::bad_alloc) {
void* const mem = std::malloc(size);
if (! mem) {

want to kick the tires on a new multithreading tool?

2008-10-04T01:13:15Z

We at Cilk Arts are soon (Jan '09) going to release Cilk++ 1.0, with the
goal of delivering the easiest, quickest, and most reliable way to maximize
application performance on multicore processors.
We have an Early Visibility Program for folks interested in kicking the
tires on the alpha/beta versions of the product and multicore-enabling their

POD function static initialization from function return, thread safe?

2008-10-03T22:07:52Z

I know that static initialization is not considered threadsafe from
previous posts on this list. However, if a function static is POD
being initialized by a function call then the value should always be
initialized correctly, even if a inconsequential race condition
occurs. This assumes that POD assignments are atomic, what platforms