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 :
Ansist
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.)
("threa
On Thu, 05 Jun 2014 09:51:05 +0200
Michael Schnell 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: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
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:37:57 +0200
Michael Schnell 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.
No. See for
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 CPUs
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 unde
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
On Wed, 04 Jun 2014 15:03:31 -0400
"Saunders, Rich" 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
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 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 indica
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 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.
Jus
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 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 wit
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.
Ch
On 6/4/2014 12:22 PM, m...@rpzdesign.com 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
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, Mich
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
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
21 matches
Mail list logo
