Thread Safety of String

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Thread Safety of String

md@rpzdesign.com
Hello:

Is a string[30] declaration under Linux thread safe?

I am not worried about atomicity, just that the memory for a string[30]
if thread safe.

For UTF8String, it is not.

I have 2 threads which are comparing/changing memory and I do not
want criticalsections wrapping the memory accesses for speed reasons.

Type
  Class TTest(TObject)
  public
    nflag : integer ;
    sflag : string[30]
  end;


Gui Thread

gtest := TTest.Create ;

Thread #1 - Constantly changing values

while true do
begin
 gtest.nflag := Random($FFFFFFFF) ;
 gtest.sflag := inttostr(gtest.nflag) ;
end;

Thread #2 - Constantly Comparing values

While true do
begin

  if gtest.nflag = 777888 then
  begin
    break ;
  end;

  //Test string matching instead of integer matching
  if gtest.sflag = '123456' then
  begin
    LaunchSpaceShuttle(gtest) ;
  end;

end;


Thanks for any replies,

marco
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Michael Van Canneyt


On Wed, 4 Jun 2014, [hidden email] wrote:

> Hello:
>
> Is a string[30] declaration under Linux thread safe?

No.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

md@rpzdesign.com
Just as I suspected.

So every time a new value is assigned to a string[30] variable, memory
is allocated and changed by the compiler, so the internal string pointer
changes as well.

And the only recourse is critical sections for memory access.

Correct?

CHeers,

marco


On 6/4/2014 1:16 PM, Michael Van Canneyt wrote:

>
>
> On Wed, 4 Jun 2014, [hidden email] wrote:
>
>> Hello:
>>
>> Is a string[30] declaration under Linux thread safe?
>
> No.
>
> Michael.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

md@rpzdesign.com
In reply to this post by Michael Van Canneyt
I guess what I was really asking is:

Is there a way to treat an array of chars as a string.

I like the string handling patterns of freepascal but I want
the memory stability of a static array of chars
so I can be used in multi-thread operations without
a lot a critical section considerations.

Cheers,

marco



On 6/4/2014 1:16 PM, Michael Van Canneyt wrote:

>
>
> On Wed, 4 Jun 2014, [hidden email] wrote:
>
>> Hello:
>>
>> Is a string[30] declaration under Linux thread safe?
>
> No.
>
> Michael.
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Craig Peterson-4
On 6/4/2014 12:22 PM, [hidden email] wrote:
> I like the string handling patterns of freepascal but I want
> the memory stability of a static array of chars
> so I can be used in multi-thread operations without
> a lot a critical section considerations.

Have you actually verified that adding a critical section makes things
noticeably slower?  You're better off starting with something that you
know is correct and optimizing it with questionable changes when you're
sure you need it.

--
Craig Peterson
Scooter Software


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

JohannS-2
In reply to this post by md@rpzdesign.com
On Wed, Jun 04, 2014 at 01:19:33PM -0400, [hidden email] wrote:

>On 6/4/2014 1:16 PM, Michael Van Canneyt wrote:
>>
>>
>> On Wed, 4 Jun 2014, [hidden email] wrote:
>>
>>> Hello:
>>>
>>> Is a string[30] declaration under Linux thread safe?
>>
>> No.
>>
>> Michael.
>
>Just as I suspected.
>
>So every time a new value is assigned to a string[30] variable, memory
>is allocated and changed by the compiler, so the internal string pointer
>changes as well.
>
>And the only recourse is critical sections for memory access.
>
>Correct?
>
>CHeers,
>
>marco

I still program in Turbo Pascal so I am more of a
spectator than a user of Free Pascal.  As I understand it
the shortstring type is the same as string type in Turbo
Pascal.  This would make index 0 of variable typed as
shortstring[SIZE] an internal length byte and index
positions 1 through SIZE the data value of the string.  
Since, unlike a newer string type, a shortstring is not an
object and not a managed string at all, but a simple type
like an integer, I would expect shortstring might be
thread safe.

Is this the case?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Saunders, Rich
In reply to this post by md@rpzdesign.com
On 2014-06-04 13:22, [hidden email] wrote:
> I guess what I was really asking is:
>
> Is there a way to treat an array of chars as a string.
>
> I like the string handling patterns of freepascal but I want
> the memory stability of a static array of chars
> so I can be used in multi-thread operations without
> a lot a critical section considerations.

Short strings (those declared with a defined length) are not as dynamic
as you fear. They should stay in place while you change their values.

The String type (declared without defined length) is the one that is
dynamic and reference counted.

--

Cheers!
Rich Saunders
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Michael Van Canneyt
In reply to this post by JohannS-2


On Wed, 4 Jun 2014, [hidden email] wrote:

> On Wed, Jun 04, 2014 at 01:19:33PM -0400, [hidden email] wrote:
>> On 6/4/2014 1:16 PM, Michael Van Canneyt wrote:
>>>
>>>
>>> On Wed, 4 Jun 2014, [hidden email] wrote:
>>>
>>>> Hello:
>>>>
>>>> Is a string[30] declaration under Linux thread safe?
>>>
>>> No.
>>>
>>> Michael.
>>
>> Just as I suspected.
>>
>> So every time a new value is assigned to a string[30] variable, memory
>> is allocated and changed by the compiler, so the internal string pointer
>> changes as well.
>>
>> And the only recourse is critical sections for memory access.
>>
>> Correct?
>>
>> CHeers,
>>
>> marco
>
> I still program in Turbo Pascal so I am more of a spectator than a user of
> Free Pascal.  As I understand it the shortstring type is the same as string
> type in Turbo Pascal.  This would make index 0 of variable typed as
> shortstring[SIZE] an internal length byte and index positions 1 through SIZE
> the data value of the string.  Since, unlike a newer string type, a
> shortstring is not an object and not a managed string at all, but a simple
> type like an integer, I would expect shortstring might be thread safe.
>
> Is this the case?

No, exactly the opposite.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

md@rpzdesign.com
In reply to this post by Saunders, Rich
For anybody who has followed this thread, there is some disagreement
over the thread safety of shortstrings.  And in this case, a shortstring
with a clearly defined maximum length.

Some have clearly said string[30] is NOT thread safe.

Rich indicated below he feels they ARE SAFE.

Hmmm.  Time for DOUBLE jeopardy.

Alex Trebeck says, "I am the son of Ansistring but I don't move around
much. My pointer is me and I am my pointer."

Answer:  What is a shortstring in Freepascal?

I am going to err on the side of caution and take Michael Van Canneyt's
version and implement it that way.

I have to implement the same thread code in C++ a little later, so there
are no shortstrings in C++, just QStrings. (oops, yeah, I use Qt also)

Cheers,

Marco


On 6/4/2014 2:13 PM, Saunders, Rich wrote:

> On 2014-06-04 13:22, [hidden email] wrote:
>> I guess what I was really asking is:
>>
>> Is there a way to treat an array of chars as a string.
>>
>> I like the string handling patterns of freepascal but I want
>> the memory stability of a static array of chars
>> so I can be used in multi-thread operations without
>> a lot a critical section considerations.
>
> Short strings (those declared with a defined length) are not as dynamic
> as you fear. They should stay in place while you change their values.
>
> The String type (declared without defined length) is the one that is
> dynamic and reference counted.
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Ewald-2

On 04 Jun 2014, at 20:42, [hidden email] wrote:

> For anybody who has followed this thread, there is some disagreement
> over the thread safety of shortstrings.  And in this case, a shortstring
> with a clearly defined maximum length.
>
> Some have clearly said string[30] is NOT thread safe.
>
> Rich indicated below he feels they ARE SAFE.
>

Actually, the question is: what do you mean by `thread safe`? So you mean it like: `the variable stays at the same place in memory (but not always, the variable can reside in a register for some time)`, like `accesses to this variable are atomic`, like `this variable will *always* be in memory at the same location (no prolonged life in registers for this bugger)`, or ...?


> Hmmm.  Time for DOUBLE jeopardy.
>
> Alex Trebeck says, "I am the son of Ansistring but I don't move around
> much. My pointer is me and I am my pointer."
>

Hmmm, JuniorString must be a cripple philosopher then ;-)

Anyway, I would be interested in the answer, as do you I suppose.


>
> I have to implement the same thread code in C++ a little later, so there
> are no shortstrings in C++, just QStrings. (oops, yeah, I use Qt also)

Time for some nitpicking..Yay! How about:
        char YourString[SIZE];

It's kind of a drudgery to handle those though, so I see why you like QStrings better :-)


--
Ewald

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Saunders, Rich
In reply to this post by md@rpzdesign.com
On 2014-06-04 14:42, [hidden email] wrote:
> For anybody who has followed this thread, there is some disagreement
> over the thread safety of shortstrings.  And in this case, a
> shortstring
> with a clearly defined maximum length.
>
> Some have clearly said string[30] is NOT thread safe.
>
> Rich indicated below he feels they ARE SAFE.

You have misinterpreted by comment. I was pointing out that short
strings are more static than the String type and not the as dynamic as
the earlier message indicated. When you assign a new value it is placed
in the same memory location as the previous value. This is not always
the case with the String type.

Whether static variables are more or less thread safe is for you to
decide since you know what you are doing with them. I don't think either
short strings or Strings are inherently more or less thread safe. It
depends on what you do with them.

--

Cheers!
Rich Saunders
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Mattias Gaertner
On Wed, 04 Jun 2014 15:03:31 -0400
"Saunders, Rich" <[hidden email]> wrote:

>[...]
> Whether static variables are more or less thread safe is for you to
> decide since you know what you are doing with them. I don't think either
> short strings or Strings are inherently more or less thread safe. It
> depends on what you do with them.

No data is "thread safe". Only code can be thread safe.

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

md@rpzdesign.com
I thought I had publicly declared what I wanted to do.

Here is the example code again for ease of reference:

Type
  Class TTest(TObject)
  public
    nflag : integer ;
    sflag : string[30]
  end;


Gui Thread

gtest := TTest.Create ;

Thread #1 - Constantly changing values

while true do
begin
 gtest.nflag := Random($FFFFFFFF) ;
 gtest.sflag := inttostr(gtest.nflag) ;
end;

Thread #2 - Constantly Comparing values

While true do
begin

  if gtest.nflag = 777888 then
  begin
    break ;
  end;

  //Test string matching instead of integer matching
  if gtest.sflag = '123456' then
  begin
    LaunchSpaceShuttle(gtest) ;
  end;

end;

Will this code be thread safe in terms of the gtest.sflag = '123456'
line never throw an exception because it is referring to stable memory
that is always less than 31 bytes.

Cheers,

marco



On 6/4/2014 3:27 PM, Mattias Gaertner wrote:

> On Wed, 04 Jun 2014 15:03:31 -0400
> "Saunders, Rich" <[hidden email]> wrote:
>
>> [...]
>> Whether static variables are more or less thread safe is for you to
>> decide since you know what you are doing with them. I don't think either
>> short strings or Strings are inherently more or less thread safe. It
>> depends on what you do with them.
>
> No data is "thread safe". Only code can be thread safe.
>
> Mattias
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

jeppe@j-software.dk
It will never throw an exception, but it will never be thread safe either.

Unless you are using the Interlocked* functions no datatype is
threadsafe on a modern processor(except for reference counting of
ansistrings, dynamic arrays, and interfaces; and all those use
Interlocked* functions under the hood).

Use semaphores or events instead if you need something fast, thread
safe, and responsive.

Den 04-06-2014 21:41, [hidden email] skrev:

> I thought I had publicly declared what I wanted to do.
>
> Here is the example code again for ease of reference:
>
> Type
>    Class TTest(TObject)
>    public
>      nflag : integer ;
>      sflag : string[30]
>    end;
>
>
> Gui Thread
>
> gtest := TTest.Create ;
>
> Thread #1 - Constantly changing values
>
> while true do
> begin
>   gtest.nflag := Random($FFFFFFFF) ;
>   gtest.sflag := inttostr(gtest.nflag) ;
> end;
>
> Thread #2 - Constantly Comparing values
>
> While true do
> begin
>
>    if gtest.nflag = 777888 then
>    begin
>      break ;
>    end;
>
>    //Test string matching instead of integer matching
>    if gtest.sflag = '123456' then
>    begin
>      LaunchSpaceShuttle(gtest) ;
>    end;
>
> end;
>
> Will this code be thread safe in terms of the gtest.sflag = '123456'
> line never throw an exception because it is referring to stable memory
> that is always less than 31 bytes.
>
> Cheers,
>
> marco
>
>
>
> On 6/4/2014 3:27 PM, Mattias Gaertner wrote:
>> On Wed, 04 Jun 2014 15:03:31 -0400
>> "Saunders, Rich" <[hidden email]> wrote:
>>
>>> [...]
>>> Whether static variables are more or less thread safe is for you to
>>> decide since you know what you are doing with them. I don't think either
>>> short strings or Strings are inherently more or less thread safe. It
>>> depends on what you do with them.
>> No data is "thread safe". Only code can be thread safe.
>>
>> Mattias
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Michael Schnell
In reply to this post by JohannS-2
On 06/04/2014 08:04 PM, [hidden email] wrote:
>  I would expect shortstring might be thread safe.
Only a simple write (not a modification) of processor-native types is
inherently atomic and thus really thread save.

So I suspect that even Int64 is not thread save (in this sense) on 32
bit CPUs: a simple write to a memory based variable is doner in two
steps and so could be preempted by the other thread, but is on a 64 bit CPU.

A modification of course is even worse (here you can use "atomic"
functions provided by the RTL).

Obviously a short string can't be re-written in a single instruction.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Mattias Gaertner
On Thu, 05 Jun 2014 09:37:57 +0200
Michael Schnell <[hidden email]> wrote:

> On 06/04/2014 08:04 PM, [hidden email] wrote:
> >  I would expect shortstring might be thread safe.
> Only a simple write (not a modification) of processor-native types is
> inherently atomic and thus really thread save.

No. See for example
http://en.wikipedia.org/wiki/Memory_barrier

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Michael Schnell
On 06/05/2014 09:42 AM, Mattias Gaertner wrote:
>
>> Only a simple write (not a modification) of processor-native types is
>> inherently atomic and thus really thread save.
> No.
What do you want to say by "No" ?
  - even a simple write might be not thread save or
  - also more complex writes are thread save
("thread save" in the sense that a write of the value can't be
interrupted by another thread and hence the other thread always reads
the coherent value - either the one before the writing or the one after
writing)

> See for example
> http://en.wikipedia.org/wiki/Memory_barrier
I understand that the implementation of memory barriers is architecture
specific and in a portable code you can't rely on a desired behavior.

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Michael Schnell
On 06/05/2014 09:51 AM, Michael Schnell wrote:
>
> I understand that the implementation of memory barriers is
> architecture specific and in a portable code you can't rely on a
> desired behavior.
>
http://en.wikipedia.org/wiki/Memory_barrier says:

"Programs which take advantage of memory visibility as implemented
rather than as specified may not be portable."

-Michael
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Mattias Gaertner
In reply to this post by Michael Schnell
On Thu, 05 Jun 2014 09:51:05 +0200
Michael Schnell <[hidden email]> wrote:

> On 06/05/2014 09:42 AM, Mattias Gaertner wrote:
> >
> >> Only a simple write (not a modification) of processor-native types is
> >> inherently atomic and thus really thread save.
> > No.
> What do you want to say by "No" ?

this:

>   - even a simple write might be not thread save or

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Thread Safety of String

Michael Schnell
On 06/05/2014 09:56 AM, Mattias Gaertner wrote:
>
>>    - even a simple write might be not thread save or
>
OK. I do see that with multi-processor archs with lacking automatic
memory barriers this in fact might be violated for misaligned variables.
(I don't doubt that such archs do exist.)
("thread save" in the sense that a write of the value can't be
interrupted by another thread and hence the other thread always reads
the coherent value - either the one before the writing or the one after
writing) .

Thanks for clearness.
-Michael


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12