I'm not sure it works properly on windows.
When I modify this to start two threads, and print out messages based on
their start/stop times, as well as a message inside the thread, I get
both ending messages before I get only a single printout from within the
threaded function. This seems to i
2017-03-17 13:09 GMT-03:00 Michael Van Canneyt :
>
> Nil.
>
> What exactly is not clear about the documentation ?
>
The documentation says ".. Note that the copy is made with the original
value of the variable ..". But, whats is the original value?
I think the documentation should be clearer abou
On Fri, 17 Mar 2017, African Wild Dog wrote:
Hello,
The documentation is not clear about the initial values of thread variables:
*"If threads are used then a copy is made for each thread (including the
main thread). Note that the copy is made with the original value of the
variable, not w
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
I found some inconsistencies a couple of months ago, but never got to
creating a bug report:
http://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg17337.html
lists.freepascal.org seems down, so I found this link.
VIncent
___
fpc-pascal mail
Wimpie Nortje schreef:
Jonas Maebe wrote:
On 18 Feb 2010, at 16:35, Wimpie Nortje wrote:
What is the difference between GetThreadID() and GetCurrentThreadID()?
There is a threadvar called "threadid" in the system unit. When a new
thread is started, GetCurrentThreadID is called to obtain
Jonas Maebe wrote:
On 18 Feb 2010, at 16:35, Wimpie Nortje wrote:
What is the difference between GetThreadID() and GetCurrentThreadID()?
There is a threadvar called "threadid" in the system unit. When a new
thread is started, GetCurrentThreadID is called to obtain the thread
id of the ne
On 18 Feb 2010, at 16:35, Wimpie Nortje wrote:
What is the difference between GetThreadID() and GetCurrentThreadID()?
There is a threadvar called "threadid" in the system unit. When a new
thread is started, GetCurrentThreadID is called to obtain the thread
id of the new thread (via the th
> 2009/10/20 :
> > The comment on line 54 should perhaps be reworded to reflect that
> > although it's not implemented in the current release, the user is free to
> > use the values if he so wishes. It's not stupid, one never knows what the
> > next guy will do with ones code.
>
> It is mentioned
2009/10/20 :
>
> The comment on line 54 should perhaps be reworded to reflect that although
> it's not implemented in the current release, the user is free to use the
> values if he so wishes. It's not stupid, one never knows what the next guy
> will do with ones code.
It is mentioned in the docu
On Thu, 15 Jan 2004, Michael Van Canneyt wrote:
> > After looking at the RTL source, I thought I needed to 'use cthreads', but
> > that didn't seem to do the job.
>
> Nevertheless, that should do it, but it should be the first unit in your
> program's uses clause.
>
> Michael.
Ah! Like heaptr
On Thu, 15 Jan 2004, Lloyd Park wrote:
> I have been playing with multi-threaded apps using fpc 1.9.0. I use the
> {$THREADING ON} directive in my code. My test program compiled and ran
> with 1.9.0, but with 1.9.2, I get the following runtime error:
>
> This binary has no thread support compi
On Tue, Sep 02, 2003 at 09:56:18AM +0200, Chemistry.rd wrote:
> From: Dancso Andras <[EMAIL PROTECTED]>
> Subject: thread
>
> Question: How can I start a new thread from FreePascal under Win32?
I think it might be platform independent. If that's the case there's a
nice example in the FCL source.
32 matches
Mail list logo
