Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #598 > unrolled thread

Threads and statically allocated buffer

Back to article view | Back to comp.programming.threads

Contents

  Threads and statically allocated buffer ittium <ittium@gmail.com> - 2011-09-22 11:47 +0530
    Re: Threads and statically allocated buffer David Schwartz <davids@webmaster.com> - 2011-09-22 14:34 -0700
      Re: Threads and statically allocated buffer ittium <ittium@gmail.com> - 2011-09-24 10:08 +0530
        Re: Threads and statically allocated buffer David Schwartz <davids@webmaster.com> - 2011-09-24 12:42 -0700
          Re: Threads and statically allocated buffer ittium <ittium@gmail.com> - 2011-09-25 11:45 +0530
            Re: Threads and statically allocated buffer David Schwartz <davids@webmaster.com> - 2011-09-25 04:15 -0700
    Re: Threads and statically allocated buffer Marcel Müller <news.5.maazl@spamgourmet.com> - 2011-09-24 09:16 +0200

#598 — Threads and statically allocated buffer

Group,
I have a situation where I am using following shared data structures


1. static buffer char B[100] where Multiple threads are copying string 
on using memcpy without any lock.

2. Shared STL string, where multiple threads are assigning values 
without locks.

There are large number of instances of #1 but few instances of #2.

The code was working fine on a quadcore machine. Recently we moved the 
system to a 16 core machine.

We saw crashes in #2 which we solve by putting mutex around the shared 
string access.

We have not seen any crash(till now in our testing) in #1, my doubt is 
whether copying of data on a statically allocated buffer by multiple 
threads results in incorrect  behavior (since variable may not have the 
value that you were expecting) or it may result in to crash also.

As pointed out earlier there are large number of instances of #2, 
protecting them is a significant effort. I can live with incorrect 
behavior but crashes obviously have to be avoided.

thanks
Ittium

[toc] | [next] | [standalone]

#600

On Sep 21, 11:17 pm, ittium <itt...@gmail.com> wrote:

> We have not seen any crash(till now in our testing) in #1, my doubt is
> whether copying of data on a statically allocated buffer by multiple
> threads results in incorrect  behavior (since variable may not have the
> value that you were expecting) or it may result in to crash also.
>
> As pointed out earlier there are large number of instances of #2,
> protecting them is a significant effort. I can live with incorrect
> behavior but crashes obviously have to be avoided.

What threading standard are we talking about? If POSIX, the
requirement is that there be some kind of synchronization preventing
an object from being modified in one thread while another thread is or
might be accessing it. Otherwise, you get undefined behavior which can
include crashes.

Incorrect behavior can almost always lead to crashes.

DS

[toc] | [prev] | [next] | [standalone]

#601

On 23-09-2011 AM 03:04, David Schwartz wrote:
> On Sep 21, 11:17 pm, ittium<itt...@gmail.com>  wrote:
>
>> We have not seen any crash(till now in our testing) in #1, my doubt is
>> whether copying of data on a statically allocated buffer by multiple
>> threads results in incorrect  behavior (since variable may not have the
>> value that you were expecting) or it may result in to crash also.
>>
>> As pointed out earlier there are large number of instances of #2,
>> protecting them is a significant effort. I can live with incorrect
>> behavior but crashes obviously have to be avoided.
>
> What threading standard are we talking about? If POSIX, the
> requirement is that there be some kind of synchronization preventing
> an object from being modified in one thread while another thread is or
> might be accessing it. Otherwise, you get undefined behavior which can
> include crashes.
>
> Incorrect behavior can almost always lead to crashes.
>
DS,
thanks for the reply.
Is there any operation that is guaranteed to be atomic ? From your 
reasoning it seems operations like ++a or a=b are also not atomic.
To maintain the data consistency, it seems imperative that threads 
should as much as possible work on local data. Shared data updates 
should be minimum and synchronized.
Naveen

[toc] | [prev] | [next] | [standalone]

#603

On Sep 23, 9:38 pm, ittium <itt...@gmail.com> wrote:

> Is there any operation that is guaranteed to be atomic ?

Your platform might have some.

> From your
> reasoning it seems operations like ++a or a=b are also not atomic.

Exactly. Some CPUs don't even have atomic increment operations. And
even if the CPU does, the compiler might see that it needs the value
later and prefer to have it in a register, so it might not use an
atomic in-memory increment even if it has one.

> To maintain the data consistency, it seems imperative that threads
> should as much as possible work on local data. Shared data updates
> should be minimum and synchronized.

In general, there is no such thing as "local data". All data is
shared. There is generally no performance difference between working
on shared or unshared data -- it's all shared.

What you want to avoid is:

1) Contention: Where one thread cannot make forward progress because
another thread has locked a resource it needs.

2) Small Locks: Where a thread is constantly having to acquire and
release locks and is unable to do a significant amount of work without
needing a synchronizing operation.

Lots of shared data doesn't mean lots of contention nor does it mean
lots of small locks.

DS

[toc] | [prev] | [next] | [standalone]

#605

On 25-09-2011 AM 01:12, David Schwartz wrote:
> On Sep 23, 9:38 pm, ittium<itt...@gmail.com>  wrote:
>
>> Is there any operation that is guaranteed to be atomic ?
>
> Your platform might have some.
>
>>  From your
>> reasoning it seems operations like ++a or a=b are also not atomic.
>
> Exactly. Some CPUs don't even have atomic increment operations. And
> even if the CPU does, the compiler might see that it needs the value
> later and prefer to have it in a register, so it might not use an
> atomic in-memory increment even if it has one.

You are saying even if there is some atomic operation available for some 
compiler+OS+CPU, this is not guaranteed to be portable, In other words, 
there is no portable atomic operation.

[toc] | [prev] | [next] | [standalone]

#609

On Sep 24, 11:15 pm, ittium <itt...@gmail.com> wrote:

> You are saying even if there is some atomic operation available for some
> compiler+OS+CPU, this is not guaranteed to be portable, In other words,
> there is no portable atomic operation.

Not in POSIX pthreads, no.

DS

[toc] | [prev] | [next] | [standalone]

#602

Hi,

ittium wrote:
> Group,
> I have a situation where I am using following shared data structures
> 
> 
> 1. static buffer char B[100] where Multiple threads are copying string 
> on using memcpy without any lock.
> 
> 2. Shared STL string, where multiple threads are assigning values 
> without locks.

both is undefined behavior, since none of these operations are atomic.


> There are large number of instances of #1 but few instances of #2.
> 
> The code was working fine on a quadcore machine. Recently we moved the 
> system to a 16 core machine.
> 
> We saw crashes in #2 which we solve by putting mutex around the shared 
> string access.

Not surprisingly.


> We have not seen any crash(till now in our testing) in #1, my doubt is 
> whether copying of data on a statically allocated buffer by multiple 
> threads results in incorrect  behavior (since variable may not have the 
> value that you were expecting) or it may result in to crash also.

#1 will not crash as long as you do not write anything else but '\0' to 
the last byte of the buffer. In this case the buffer is always zero 
terminated. Only the string could be mincemeat. Normally, it makes no 
sense to read a string with an undefined content. And it makes no sense 
to write a buffer that nobody can reasonable read. So what it is all 
about? What semantics are you going to implement?


> As pointed out earlier there are large number of instances of #2, 

Above you you said 'few instances of #2'.

> protecting them is a significant effort. I can live with incorrect 
> behavior but crashes obviously have to be avoided.

#1 will not crash, if you are aware of buffer overruns. It will report 
incorrect data. But keep in mind that any access to it will be in the 
order of 150 CPU cycles on x86/x64 multi-core, because of the cache 
invalidations. Architectures without synchronized caches might perform 
better but the reading the buffer is even less reliable. In this case, 
each thread will primarily see its own output, nothing else. Undefined 
behavior has many surprises.

#2 is only safe if you synchronize write access to the strings as well 
as read access. Everything else is subject to crash sooner or later. You 
have to fix this, if you are responsible for the quality of your 
application in any way.
If you are seeking for a lock-free solution keep in mind that you will 
need strong thread safety, because you must ensure the old buffer 
content to be valid until all threads that have read the string pointer 
recently do not use the content anymore. There have been a long 
discussion about this topic in this group several months ago.


Marcel

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming.threads

csiph-web