On 29/06/2011 16:11, Michael Schnell wrote:
On 06/28/2011 08:14 PM, Hans-Peter Diettrich wrote:
I just found a very nice description of some aspects of thread safety in
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_09_08
titled Thread-Safety.
Great.
Lukasz Sokol schrieb:
On 29/06/2011 16:11, Michael Schnell wrote:
On 06/28/2011 08:14 PM, Hans-Peter Diettrich wrote:
I just found a very nice description of some aspects of thread safety in
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_09_08
titled
On 30/06/2011 11:14, Hans-Peter Diettrich wrote:
Lukasz Sokol schrieb:
[...]
How is the 'thread safety for classses' different from thread
safety for any other code ?
Thread-safety has many facettes. An item may be safe in one aspect,
e.g. not using global variables, but unsafe in other
On 06/30/2011 10:09 AM, Lukasz Sokol wrote:
On 29/06/2011 16:11, Michael Schnell wrote:
How is the 'thread safety for classses' different from
thread safety for any other code ?
This already has been discussed in this thread previously.
-Michael
--
On 06/30/2011 01:53 PM, Lukasz Sokol wrote:
After compilation, it's just code, isn't it?
Yep but the programmer that writes the code using an existing object and
reading it's docs does not see the code after compilation. He is
inclined to consider the functions of multiple instances of a
On 06/30/2011 01:53 PM, Lukasz Sokol wrote:
AFAIR, code (whatever way you write it) can either BE safe or NOT, no
half measyres here - any one of the 'properties' vel 'aspects' not
complied with, and you can't name your code thread-safe.
A function easily can be thread safe _only_ if a
Lukasz Sokol schrieb:
Objects (classes) add further topics to the list of items, that make
up thread-safety in general.
After compilation, it's just code, isn't it?
Classes may have the 'hidden' variables but they're not 'hidden' to the
OS/CPU ?
Objects include information, that may be
On Tue, Jun 28, 2011 at 2:32 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Andrew Brunner schrieb:
In a bidirectionally linked list up to 4 pointers have to be updated
together, whenever an element is inserted or removed. This leaves much
room
for race conditions, that cannot be cured
On 06/28/2011 08:34 PM, Hans-Peter Diettrich wrote:
Another aspect seems to be the synchronization of *all* data, in *all*
caches. Is this correct, or do I expect too much?
Not necessary (e.g.) on detecting that a cache line resides in multiple
caches doing an immediate write back and
On 06/28/2011 08:14 PM, Hans-Peter Diettrich wrote:
I just found a very nice description of some aspects of thread safety in
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_09_08
titled Thread-Safety.
Great.
Niche background information on Posix.
But it
Hello Lazarus-List,
Wednesday, June 29, 2011, 5:09:22 PM, you wrote:
*** This one must work
Thread/core/processor 2
---
while true do begin
Critical.Enter;
if ab then Raise Exception.Create('KBOOM!');
Critical.Leave;
end;
If the second one will not work in
On Tue, 28 Jun 2011 04:18:55 +0200
Reimar Grabowski reimg...@web.de wrote:
On Mon, 27 Jun 2011 18:41:46 -0500
Andrew Brunner andrew.t.brun...@gmail.com wrote:
This is relatively new theory which required low-level CPU code to
perform such locks. This was never needed until the
On 06/27/2011 08:03 PM, Andrew Brunner wrote:
entercricitalsection();
loop
a:=b+c;
end loop;
leavecriticalsection();
thread 2
can read a and b and c at any state. If you want an accurate view of
a,b,c you need to employ interlocked statements :-)
Hmm.
In this example, b and c are not
On 06/28/2011 12:31 AM, Andrew Brunner wrote:
2.) Execution Order.
As a critical section is a function call, it prevents instructions are
re-ordered from being inside of the protected code sequence to being
outside. And what happens inside the protected code sequence is not
prone to mutual
On 06/28/2011 01:41 AM, Andrew Brunner wrote:
2011/6/27 Malcom Haakinsane...@gmail.com:
In fact in cases
this this the use of CriticalSections would be sensible and
Thread 1:
...
This is relatively new theory which required low-level CPU code to
perform such locks. This was never needed until
On 06/28/2011 10:48 AM, Michael Schnell wrote:
...
I forgot to mention that the variables a and b need to be defined as
volatile (mentioning this C-keyword) and thus need to be global/static
which makes Pascal to handle them as volatile (not cashing them in CPU
registers). I don't know if/how
On 28/06/11 11:13, Henry Vermaak wrote:
On 27/06/11 23:31, Andrew Brunner wrote:
AMD vs Intel. Kernels Linux vs Windows. The only way to make sure
How does the kernel matter?
Other than the cpu, compilers can also reorder instructions. You can use
__asm__ __volatile__(: : :memory) in c to
On 06/28/2011 12:13 PM, Henry Vermaak wrote:
Other than the cpu, compilers can also reorder instructions.
AFAIK modern CPUs can do on the fly instruction reordering and Register
renaming, but (other than speed) this should be transparent ant not
detectable when looking at what the CPU
Marco van de Voort schrieb:
On Mon, Jun 27, 2011 at 03:05:36PM +0100, Hans-Peter Diettrich wrote:
OOP is just a convenient abstraction, it's for people needed only :)
OOP is for designers, not for hackers ;-)
When some thread-safe code must never bring a program (automaton,
system...) into
Andrew Brunner schrieb:
On Mon, Jun 27, 2011 at 2:51 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Absolutely incorrect.
Why?
Two reasons.
1.) Visibility. A critical section does not particularly protect
visibility as with 2 threads accessing a piece of memory.
This is exactly
Andrew Brunner schrieb:
This is relatively new theory which required low-level CPU code to
perform such locks.
This is not new. String operations (CMPS...) can be interrupted since a
long time, and it took some more time until even the single-core CPUs
could resume such an interrupted
Henry Vermaak wrote:
On 27/06/11 23:31, Andrew Brunner wrote:
2.) Execution Order. A critical section does not protect or ensure
that code will be executed in any particular order. This is where
How do you know this? Unfortunately I can't read the code for the
Windows critical sections
On 06/28/2011 12:44 PM, Hans-Peter Diettrich wrote:
This is exactly what I wanted to say. A critical section does *not*
enforce a MB (by visibility).
All references I read today say that pthread_mutex (on which supposedly
TCriticalSection is based) and the appropriate Windows stuff does
2011/6/27 Malcom Haak insane...@gmail.com:
OF WHAT? bad code? It would only look different if you are looking at
different parts of memory.. or you hadn't finished writing.
Are you serious?
Also what the hell are you on about? You could use CriticalSections in your
example and it would work
On 06/28/2011 12:35 PM, Hans-Peter Diettrich wrote:
*and* an according implementation of this model in application
specific code.
Yep but the application program should not (need to) be aware of what
architecture (Processor-Type, SMP,...) it is running on nor know about
the underlying OS or
On Tue, Jun 28, 2011 at 7:40 AM, Michael Schnell mschn...@lumino.de wrote:
All references I read today say that pthread_mutex (on which supposedly
TCriticalSection is based) and the appropriate Windows stuff does contain an
MB. But there might be issues with other OSes and Archs.
Yes, any
On 28/06/11 11:43, Michael Schnell wrote:
On 06/28/2011 12:24 PM, Henry Vermaak wrote:
To add to this, on x86 the memory barrier is probably implemented with
an atomic instruction.
Like MUTEX/FUTEX (and critical section) on the system level all this
needs to be done using atomic (and with
On 06/28/2011 02:47 PM, Andrew Brunner wrote:
Yes, any object that requires atomic features will employ a memory
barrier.
That is to say the MB is employed in order for the spincount to be
accurate across all cores.
As for a user program the only way to handle atomic operations is to
protect
On Tue, Jun 28, 2011 at 8:00 AM, Michael Schnell mschn...@lumino.de wrote:
As said before besides all this complicated stuff the critical variable
needs to be handled as volatile by the compiler (not caching it in a
register while opening or closing the critical section). I have no Idea how
On 06/28/2011 03:00 PM, Andrew Brunner wrote:
There is no complicated stuff. Just use interlocked
assignments for high performance computing :-)
This is low level stuff and not what user programs are supposed to do.
User land programs only know Posix as their system interface.
If the
On Tue, Jun 28, 2011 at 8:27 AM, Michael Schnell mschn...@lumino.de wrote:
On 06/28/2011 03:00 PM, Andrew Brunner wrote:
There is no complicated stuff. Just use interlocked
assignments for high performance computing :-)
This is low level stuff and not what user programs are supposed to do.
On 06/28/2011 03:30 PM, Andrew Brunner wrote:
LOL All the Interlocked / Compare and Swap statements are included in
the system unit and are readily available and tested (at least on
AMD).
I don't know an IDE called AMD ;-) .
I already did some research and found that on ARM there seem to be
Henry Vermaak schrieb:
You'll have to read the generated assembler for Windows critical
sections. My hunch would be that they use memory barriers, too.
When a critical section object is owned, the only other threads affected
are the threads that are waiting for ownership in a call to
Michael Schnell schrieb:
On 06/27/2011 07:52 PM, Hans-Peter Diettrich wrote:
You forget the strength of protection.
Maybe I seem to see what you mean.
You think, a critical section will not prevent that the data that is
accessed by both threads is duplicated in a register or in the Data
On Tue, Jun 28, 2011 at 9:47 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
I don't see anything like memory barriers here.
Compare and swap mechanisms aren't quite like memory barriers but they
to get the CPU to send a fresh copy of a variable to all cores'
cache...
--
On 06/28/2011 05:33 PM, Hans-Peter Diettrich wrote:
A critical section (process-local MUTEX) is not related to a specific
(memory) resource, except itself, consequently it can not protect any
*other* resource. It also does not block any other thread, not waiting
for entering the critical
On 28/06/11 15:47, Hans-Peter Diettrich wrote:
Henry Vermaak schrieb:
You'll have to read the generated assembler for Windows critical
sections. My hunch would be that they use memory barriers, too.
When a critical section object is owned, the only other threads affected
are the threads
On 06/28/2011 05:33 PM, Hans-Peter Diettrich wrote:
No. In a bidirectionally linked list up to 4 pointers have to be
updated together, whenever an element is inserted or removed. This
leaves much room for race conditions, that cannot be cured by
protecting every single pointer. Instead the
On Tue, Jun 28, 2011 at 10:33 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Big Q: *which* resource?
A critical section (process-local MUTEX) is not related to a specific
(memory) resource, except itself, consequently it can not protect any
*other* resource. It also does not block any
On Tue, Jun 28, 2011 at 9:59 AM, Michael Schnell mschn...@lumino.de wrote:
But the original claim was that the implementation with Critical sections
failed on a multi core engine and interlocked instructions helped.
This is why I suggested that there is some kind of bug.
LOL I don't recall
On 06/23/2011 12:37 AM, Malcom Haak wrote:
Correct me if I'm wrong, But can't you technically make any code
'thread-safe' by using Critical Sections before doing work.
Of course you are correct. But this is not a decent way to go.
1) the calls of CriticalSection themselves can slow down the
On 06/23/2011 07:50 AM, Hans-Peter Diettrich wrote:
I may be wrong here, because I used threads only on realtime systems,
never in Delphi or Lazarus...
Threads can help to greatly improve the soft realtime behavior of a
Delphi/Lazarus program. We do this a lit.
BTW, I just got my copy of RAD
On Thu, Jun 23, 2011 at 06:50:14AM +0100, Hans-Peter Diettrich wrote:
BTW, I just got my copy of RAD Studio XE, where e.g. thread.suspend is
deprecated,
So is FPC 2.4.4.
and other means for thread synchronization are added.
Afaik they only added start as a replacements for
On Mon, 27 Jun 2011, Michael Schnell wrote:
On 06/23/2011 07:50 AM, Hans-Peter Diettrich wrote:
I may be wrong here, because I used threads only on realtime systems, never
in Delphi or Lazarus...
Threads can help to greatly improve the soft realtime behavior of a
Delphi/Lazarus program. We
On 06/23/2011 02:02 PM, Andrew Brunner wrote:
With multi-core systems simply adding a mutex/lock is not enough.
A MUTEX or FUTEX (or CriticalSection) is supposed to work as expected on
multi-Core systems as well. User code is not supposed to need to bother
about running on a multi-core
On 06/27/2011 11:29 AM, michael.vancann...@wisa.be wrote:
So it's the MS engineers who were drunk, I suppose.
I don't doubt this :-) :-) :-) .
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 22/06/2011 23:37, Malcom Haak wrote:
Correct me if I'm wrong, But can't you technically make any code
'thread-safe' by using Critical Sections before doing work.
I don't think so.
If the function, for example stores some important data in a thread
local variable, but flags (thread
On 27/06/2011 10:31, Michael Schnell wrote:
On 06/27/2011 11:29 AM, michael.vancann...@wisa.be wrote:
So it's the MS engineers who were drunk, I suppose.
I don't doubt this :-) :-) :-) .
-Michael
Must have been something to do with the Ballmer Peak
http://xkcd.com/323/ :)
L.
--
On 06/27/2011 11:37 AM, Martin wrote:
If the function, for example stores some important data in a thread
local variable, but flags (thread global) the availability of the
data, then no Critical section will fix it.
Yep !
As stated in my former messages in this thread, IMHO, the official
On 27/06/2011 11:19, Michael Schnell wrote:
On 06/27/2011 11:37 AM, Martin wrote:
If the function, for example stores some important data in a thread
local variable, but flags (thread global) the availability of the
data, then no Critical section will fix it.
Yep !
As stated in my former
On 27/06/2011 11:58, Martin wrote:
On 27/06/2011 11:19, Michael Schnell wrote:
On 06/27/2011 11:37 AM, Martin wrote:
If the function, for example stores some important data in a thread
local variable, but flags (thread global) the availability of the
data, then no Critical section will fix
On 27/06/2011 11:19, Michael Schnell wrote:
On 06/27/2011 11:37 AM, Martin wrote:
If the function, for example stores some important data in a thread
local variable, but flags (thread global) the availability of the
data, then no Critical section will fix it.
Yep !
As stated in my
On 06/27/2011 12:51 PM, Martin wrote:
Why? Where does the definition conflict with the above?
A piece of code is *thread-safe* if it can be safely invoked by
multiple threads at the same time
It does not *conflict* it is just not useful.
The problem is not safe invocation the problem is
On 27/06/2011 12:23, Michael Schnell wrote:
On 06/27/2011 12:51 PM, Martin wrote:
Why? Where does the definition conflict with the above?
A piece of code is *thread-safe* if it can be safely invoked by
multiple threads at the same time
It does not *conflict* it is just not useful.
The
On 10/06/2011 12:26, Henry Vermaak wrote:
On 10/06/11 02:09, Hans-Peter Diettrich wrote:
What is thread safe?
The definition is very clear here:
http://en.wikipedia.org/wiki/Thread_safety
A piece of code is *thread-safe* if it can be safely invoked by
multiple threads at the same time
There is no question that we all agree about the technical background of
all this.
The discussion I started was just about what (new) definitions makes
sense to be provided in the docs to the user of an Object language to
allow him to decide which object (e.g. TList vs. TThreadList) he needs
On 27/06/2011 13:57, Michael Schnell wrote:
There is no question that we all agree about the technical background
of all this.
The discussion I started was just about what (new) definitions makes
sense to be provided in the docs to the user of an Object language to
allow him to decide which
Martin laza...@mfriebe.de hat am 27. Juni 2011 um 14:47 geschrieben:
On 10/06/2011 12:26, Henry Vermaak wrote:
On 10/06/11 02:09, Hans-Peter Diettrich wrote:
What is thread safe?
The definition is very clear here:
http://en.wikipedia.org/wiki/Thread_safety
On Mon, Jun 27, 2011 at 7:57 AM, Michael Schnell mschn...@lumino.de wrote:
There is no question that we all agree about the technical background of all
this.
Actually,
There was no mention of memory barriers other than the content in my
post. So if you want to understand what that is here is
Michael Schnell mschn...@lumino.de hat am 27. Juni 2011 um 14:57 geschrieben:
There is no question that we all agree about the technical background of
all this.
The discussion I started was just about what (new) definitions makes
sense to be provided in the docs to the user of an
Martin schrieb:
As stated in my former messages in this thread, IMHO, the official
definition of thread-safe-ness does not make much sense with objects,
but a more complex definition covering several cases of use is necessary.
Why? Where does the definition conflict with the above?
A piece
Lukasz Sokol schrieb:
The computer/OS/system has no clue of anything you may call 'an object'...
when compiled, it is just 'code'.
Right.
OOP is just a convenient abstraction, it's for people needed only :)
OOP is for designers, not for hackers ;-)
When some thread-safe code must never
On 06/27/2011 03:31 PM, Andrew Brunner wrote:
Simply protecting a loop with a futex is not sufficient. Assigning
variables in a multi-threaded environment is not sufficient.
While I don't think we should this discuss in this context, I suggest
that in the docs for the user of the object
On 06/27/2011 03:34 PM, Mattias Gaertner wrote:
The documentation can simply say about TList:
Thread safe: no
Used non thread safe global variables: none
Poor user !
If he just reads Thread safe: no, he supposedly will believe he needs to
use TThreadList in all threads and do very
On 27/06/2011 14:23, Mattias Gaertner wrote:
What is thread safe?
The definition is very clear here:
http://en.wikipedia.org/wiki/Thread_safety
A piece of code is *thread-safe* if it can be safely invoked by
multiple threads at the same time
Just to point out first, I am aware of the
Martin laza...@mfriebe.de hat am 27. Juni 2011 um 16:01 geschrieben:
[...]
Think about safely invoked as no need for extra precautions to call it
multi threaded, like e.g. critical sections or check which thread is
running.
Obviously thread-safe does not extend the safety nor
On 06/27/2011 04:17 PM, Andrew Brunner wrote:
See the link at wikipedia.
I don't think Wikipedia can explain implementation details of the LCL/RTL..
But if TCriticalSection uses a MUTEX (which in fact is a FUTEX as (on
Linux) it uses pthreadlib mutex function from LibC, which automatically
Martin schrieb:
See my example about memory alloc in my other mail. It shows, that a
piece of code (and it's ability to be safely invoked ) does not solely
depend on the parameters passed, but also on (selected parts of) the
state of the application or system.
What when some code does not
Andrew Brunner schrieb:
I ran tests on a HexCore AMD system which had unexplained anomalies
with pointers in an bidirectional linked list. I replaced all the
pointer assignments with InterlockedExchange and the system worked
flawlessly. Some of the assignments were taking place in a
You're totally underestimating the need for a memory barrier :
Multithreaded programming and memory visibility
See also: Memory model (computing)
Multithreaded programs usually use synchronization primitives provided
by a high-level programming environment, such as Java and .NET
Framework, or an
On 06/27/2011 04:15 PM, Mattias Gaertner wrote:
A new term would need explanation too.
Yep. In a central location, so the feature lists for the objects is not
polluted.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
On 27/06/2011 15:58, Hans-Peter Diettrich wrote:
Martin schrieb:
See my example about memory alloc in my other mail. It shows, that a
piece of code (and it's ability to be safely invoked ) does not
solely depend on the parameters passed, but also on (selected parts
of) the state of the
On 06/27/2011 04:58 PM, Andrew Brunner wrote:
You're totally underestimating the need for a memory barrier :
While I do know that memory barriers are the way to go to avoid the
expensive use of Mutex and friends, I am positive that an MB is not
necessary if all accesses to something are
Hans-Peter Diettrich drdiettri...@aol.com hat am 27. Juni 2011 um 16:58
geschrieben:
Martin schrieb:
See my example about memory alloc in my other mail. It shows, that a
piece of code (and it's ability to be safely invoked ) does not solely
depend on the parameters passed, but
On 27/06/2011 15:05, Hans-Peter Diettrich wrote:
Lukasz Sokol schrieb:
The computer/OS/system has no clue of anything you may call 'an
object'... when compiled, it is just 'code'.
Right.
OOP is just a convenient abstraction, it's for people needed only
:)
OOP is for designers, not
On Mon, Jun 27, 2011 at 12:52 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
You forget the strength of protection. A MB will disallow immediately any
concurrent access to the memory area - no way around. Protection by other
means only can work in *perfect* cooperation, a very weak model.
Andrew Brunner schrieb:
On Mon, Jun 27, 2011 at 12:52 PM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
You forget the strength of protection. A MB will disallow immediately any
concurrent access to the memory area - no way around. Protection by other
means only can work in *perfect*
On Mon, Jun 27, 2011 at 03:05:36PM +0100, Hans-Peter Diettrich wrote:
OOP is just a convenient abstraction, it's for people needed only :)
OOP is for designers, not for hackers ;-)
When some thread-safe code must never bring a program (automaton,
system...) into an inconsistent state,
On Mon, 27 Jun 2011 18:41:46 -0500
Andrew Brunner andrew.t.brun...@gmail.com wrote:
This is relatively new theory which required low-level CPU code to
perform such locks. This was never needed until the introduction of
multi-core systems.
Excuse my ignorance but what is different on
On Tue, Jun 28, 2011 at 9:41 AM, Andrew Brunner
andrew.t.brun...@gmail.comwrote:
2011/6/27 Malcom Haak insane...@gmail.com:
Tell me then why any of what you have said is relevant. In fact in cases
this this the use of CriticalSections would be sensible and would not
cause
'tons of wait'
2011/6/22 Malcom Haak insane...@gmail.com:
Correct me if I'm wrong, But can't you technically make any code
'thread-safe' by using Critical Sections before doing work.
In some code I have seen before a critical section was entered before
calling TList.Add
Now provided that you don't need a
Malcom Haak schrieb:
Correct me if I'm wrong, But can't you technically make any code
'thread-safe' by using Critical Sections before doing work.
In some code I have seen before a critical section was entered before
calling TList.Add
IMO this won't help, because any other thread that does
On Tue, 14 Jun 2011 11:53:14 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/10/2011 06:09 PM, Mattias Gaertner wrote:
Sigh. It already does. See my TThreadList.Add example.
This example shows that it does not make sense.
(Supposedly) TThreadList.Add is separate-instance-thread
On 14/06/11 10:53, Michael Schnell wrote:
On 06/10/2011 06:09 PM, Mattias Gaertner wrote:
Sigh. It already does. See my TThreadList.Add example.
This example shows that it does not make sense.
(Supposedly) TThreadList.Add is separate-instance-thread safe (each
thread can create an instance
On 06/14/2011 12:02 PM, Mattias Gaertner wrote:
Why do you think so?
Sorry I have been typing much faster than thinking here (again). I had
meant to be talking about TTlist. :-[ :-[ :-[
So once again:
(Supposedly)
Everything is separate-instance-thread safe. How can something be
unsafe if only one thread is accessing it?
As soon as you use global variables. E.G. Application uses global
variables, as well internally, as implicitly by doing calls to an
external Widget set. That is why the LCL is known
On Tue, 14 Jun 2011 13:26:07 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/14/2011 12:02 PM, Mattias Gaertner wrote:
Why do you think so?
Sorry I have been typing much faster than thinking here (again). I had
meant to be talking about TTlist. :-[ :-[ :-[
Your mails contain so many
The fact that I am a paranoiac does not mean that they are not after me
;-) :-P :-D .
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 06/14/2011 04:57 PM, Hans-Peter Diettrich wrote:
How would you expect a thread-safe version to work? A TList doesn't
serialize requests, this would have to be added separately.
It does not need to, as separate-instance-thread safe means that each
thread handles only it's own instance.
On Sat, Jun 11, 2011 at 02:41:03AM +0100, Hans-Peter Diettrich wrote:
threads at the same time.
Which piece of code can *not* be safely invoked?
Instead I'd define thread safety as the *absence* of possible data or
state inconsistencies in concurrent execution [of threads].
The
On Fri, 10 Jun 2011 03:09:07 +0200
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Mattias Gaertner schrieb:
Only if the documentation explicitly says a method is thread safe it is.
Maybe this needs to be made more clear. Any ideas, where?
What is thread safe?
On 06/10/2011 03:09 AM, Hans-Peter Diettrich wrote:
What is thread safe?
IMHO, quite often, this needs further explanation in the docs.
e.g. if the code in question defines a class the diversification is
generated by the potential use of class variables and global variables:
- Are you
On 10/06/11 02:09, Hans-Peter Diettrich wrote:
What is thread safe?
The definition is very clear here:
http://en.wikipedia.org/wiki/Thread_safety
In how far is just FileExistsUTF8 thread safe? Even if the file
existed at function return, it can have been killed by somebody else
immediately
On Fri, 10 Jun 2011 12:49:59 +0200
Hans-Peter Diettrich drdiettri...@aol.com wrote:
Mattias Gaertner schrieb:
Only if the documentation explicitly says a method is thread safe it is.
Maybe this needs to be made more clear. Any ideas, where?
What is thread safe?
On 06/10/2011 01:26 PM, Henry Vermaak wrote:
On 10/06/11 02:09, Hans-Peter Diettrich wrote:
What is thread safe?
The definition is very clear here:
http://en.wikipedia.org/wiki/Thread_safety
clear does not imply useful :) .
With piece of code they obviously mean a single function (or
On Fri, 10 Jun 2011 13:52:35 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/10/2011 01:26 PM, Henry Vermaak wrote:
On 10/06/11 02:09, Hans-Peter Diettrich wrote:
What is thread safe?
The definition is very clear here:
http://en.wikipedia.org/wiki/Thread_safety
clear does
On 06/10/2011 02:18 PM, Mattias Gaertner wrote:
E.g. Regarding Objects this is not enough.
Prove?
Theory: with multiple instances, the same piece of code behaves
differently, according to to the states that are stored internally in an
instance.
It's not practical to just ignore this as a
On Fri, 10 Jun 2011 14:36:36 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/10/2011 02:18 PM, Mattias Gaertner wrote:
E.g. Regarding Objects this is not enough.
Prove?
Theory: with multiple instances, the same piece of code behaves
differently, according to to the states that are
On 06/10/2011 03:32 PM, Mattias Gaertner wrote:
If the definition says it can be safely invoked by multiple threads at
the same time then it means it can be invoked by any thread in any order at
any time and the code still performs its task.
But what is it.
The wiki says: piece of code. With
On Fri, 10 Jun 2011 15:45:35 +0200
Michael Schnell mschn...@lumino.de wrote:
On 06/10/2011 03:32 PM, Mattias Gaertner wrote:
If the definition says it can be safely invoked by multiple threads at
the same time then it means it can be invoked by any thread in any order
at any time and
1 - 100 of 113 matches
Mail list logo
