On 06/04/2014 08:04 PM, joha...@nacs.net 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
On Thu, 05 Jun 2014 09:37:57 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/04/2014 08:04 PM, joha...@nacs.net 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.
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
On Thu, 05 Jun 2014 09:51:05 +0200
Michael Schnell mschn...@lumino.de 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:
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.)
My point of view after looking at the code.
This code is not thread safe.
Discussion
gtest.sflag := inttostr(gtest.nflag) ; - will call
fpc_AnsiStr_To_ShortStr
fpc_AnsiStr_To_ShortStr is programmed as :
procedure fpc_AnsiStr_To_ShortStr (out res: shortstring; const S2 :
On Wed, 4 Jun 2014, m...@rpzdesign.com wrote:
Hello:
Is a string[30] declaration under Linux thread safe?
No.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
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,
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.
On 2014-06-04 13:22, m...@rpzdesign.com 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
On Wed, Jun 04, 2014 at 01:19:33PM -0400, m...@rpzdesign.com wrote:
On 6/4/2014 1:16 PM, Michael Van Canneyt wrote:
On Wed, 4 Jun 2014, m...@rpzdesign.com wrote:
Hello:
Is a string[30] declaration under Linux thread safe?
No.
Michael.
Just as I suspected.
So every time a new value is
On Wed, 4 Jun 2014, joha...@nacs.net wrote:
On Wed, Jun 04, 2014 at 01:19:33PM -0400, m...@rpzdesign.com wrote:
On 6/4/2014 1:16 PM, Michael Van Canneyt wrote:
On Wed, 4 Jun 2014, m...@rpzdesign.com wrote:
Hello:
Is a string[30] declaration under Linux thread safe?
No.
Michael.
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
On 2014-06-04 14:42, m...@rpzdesign.com 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
On 04 Jun 2014, at 20:42, m...@rpzdesign.com 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.
On Wed, 04 Jun 2014 15:03:31 -0400
Saunders, Rich greym...@mykolab.com 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.
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
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
18 matches
Mail list logo
