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 s
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 parameter
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 class
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 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 i
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 "Thread-
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".
>
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 a<>b then Raise Exception.Create('KBOOM!');
>>Critical.Leave;
>> end;
>>
>> If the second
On Wed, Jun 29, 2011 at 10:04 AM, Michael Schnell wrote:
> But correct Posix compliant code is supposed to work on hardware with any
> count of cores. So there seems to be a bug _somewhere_.
>From what I observed and read, using Interlocked assignments or
Compare and Swap was designed to explicit
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
On 06/28/2011 07:06 PM, José Mejuto wrote:
*** This one must work
Thread/core/processor 2
---
while true do begin
Critical.Enter;
if a<>b then Raise Exception.Create('KBOOM!');
Critical.Leave;
end;
If the second one will not work in a n-code processor, or SMP, please
On 06/28/2011 06:44 PM, Andrew Brunner wrote:
but back it up with facts no opinions.
Posix.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
On 06/28/2011 06:02 PM, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 9:59 AM, Michael Schnell wrote:
This is why I suggested that there is some kind of bug.
LOL I don't recall you ever asking specifics on my implementation.
I did not claim that the big is in your implementation,. It might b
On 06/28/2011 08:59 PM, Hans-Peter Diettrich wrote:
sounds nice, but it does not hinder any other code to do something
with the same variables, at the same time, *without* entering the CS.
Of course a CS only makes sense if all code accessing the data in
question is done using the same CS. So
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 invalid
On Tue, Jun 28, 2011 at 2:32 PM, Hans-Peter Diettrich
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 by pro
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 by protecting every single
pointer. Instead the entire chain must be protected, by a
Michael Schnell schrieb:
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
Henry Vermaak schrieb:
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 a
Hans-Peter Diettrich schrieb:
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"?
Self-comment:
I just found a very nice description of some aspects of thread saf
Hello Lazarus-List,
Tuesday, June 28, 2011, 6:44:17 PM, you wrote:
I can only talk about Win x86, so things could be different in other
OS.
AB> Your assumption would be incorrect. The system doesn't do anything
AB> but decrease the spincount of the criticalsection object to make sure
AB> the va
On Tue, Jun 28, 2011 at 9:59 AM, Michael Schnell wrote:
> I fully agree. With the RTL/LCL, the MUTEX is encapsulated in the
> TCtriticalSection Object (one MUTEX per instance. And of course, here, a
> single instance is necessary to be used for all accesses to the pointers).
> And as the Mutex al
On Tue, Jun 28, 2011 at 9:59 AM, Michael Schnell 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 you ever asking
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 en
On Tue, Jun 28, 2011 at 10:33 AM, Hans-Peter Diettrich
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 other thread, n
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:
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 sec
On Tue, Jun 28, 2011 at 9:47 AM, Hans-Peter Diettrich
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...
--
___
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
cac
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
En
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
On Tue, Jun 28, 2011 at 8:27 AM, Michael Schnell 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.
> User la
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 perform
On Tue, Jun 28, 2011 at 8:00 AM, Michael Schnell 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
> this can be enf
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 th
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 SM
On Tue, Jun 28, 2011 at 7:40 AM, Michael Schnell 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 object that requir
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
2011/6/27 Malcom Haak :
> 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 fine. The fact
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
conta
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 an
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 instru
Andrew Brunner schrieb:
On Mon, Jun 27, 2011 at 2:51 PM, Hans-Peter Diettrich
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 what I wanted to say. A
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 an
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 SMP bus locking / cache
invalidating) ins
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 actually
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 28/06/11 10:22, 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 criti
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 stop gcc from screwing
around wit
On 06/27/2011 08:01 PM, Andrew Brunner wrote:
That all changed with the introduction of multi-core systems. But in
those days everything was inline. Now a days everything is running
in parallel.
Yep. But the user application code just sees threads.
Since ages, the user code needs to consid
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 and the documentation do
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 06/28/2011 01:41 AM, Andrew Brunner wrote:
2011/6/27 Malcom Haak:
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 the introduction of
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 ac
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 modi
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
cache of the two (or more) CP
On Tue, 28 Jun 2011 04:18:55 +0200
Reimar Grabowski wrote:
> On Mon, 27 Jun 2011 18:41:46 -0500
> Andrew Brunner 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.
>
>
On Tue, Jun 28, 2011 at 9:41 AM, Andrew Brunner
wrote:
> 2011/6/27 Malcom Haak :
> > 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' as you have all your worker threads off
On Mon, 27 Jun 2011 18:41:46 -0500
Andrew Brunner 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 multi-core systems compared to
2011/6/27 Malcom Haak :
> 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' as you have all your worker threads off doing things 99% of
> the time.
Thread 1:
a=b+c
a2=a+c2
SignalEv
However there are MANY cases where execution order does not matter. These
are the BEST cases for threads.
In most of these cases there is a long list of work to be done, none of
which references any of the other work. Some examples include brute force
solving of complex hashing functions,
downloadi
On Mon, Jun 27, 2011 at 2:51 PM, Hans-Peter Diettrich
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.
2.) Execution Order. A critical section does not protect or
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 sta
Andrew Brunner schrieb:
On Mon, Jun 27, 2011 at 12:52 PM, Hans-Peter Diettrich
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 mod
On Mon, Jun 27, 2011 at 12:52 PM, Hans-Peter Diettrich
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.
Absolutely incor
On Mon, Jun 27, 2011 at 1:05 PM, Hans-Peter Diettrich
wrote:
> And this is not related to thread-safety at all. The "safe call" means
> nothing but *reentrant*.
>
That all changed with the introduction of multi-core systems. But in
those days everything was inline. Now a days everything is run
Martin schrieb:
When in case of an unexpected error the called procedure throws an
exception? Can this procedure *ever* be "safely invoked", when it may
return to some other place in code (exception handler)?
Yes, why not. IF this is the defined behaviour. Exceptions can be
caught. To safely
Michael Schnell schrieb:
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 accesse
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 de
Hans-Peter Diettrich 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 also on (se
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 protect
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 appl
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
http:/
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
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
criticalse
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
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
us
Martin 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 does it
2011/6/27 Michael Schnell :
> This is clear. You also would have been able to avoid the problem by using
> critical sections around all the appropriate instructions, but supposedly
> this would have slowed done the application greatly.
>
I disagree. In my experience critical sections only employ
Michael Schnell hat am 27. Juni 2011 um 15:54 geschrieben:
> 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
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
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 ineffic
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 library
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 br
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 pie
Michael Schnell 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 Object languag
On Mon, Jun 27, 2011 at 7:57 AM, Michael Schnell 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 a link...
http:/
Martin 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 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 obje
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 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"
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 pr
On 06/27/2011 01:07 PM, Lukasz Sokol wrote:
The computer/OS/system has no clue of anything you may call 'an object'...
when compiled, it is just 'code'.
Yep.
But before compiling this is different from the "user" 's point of view:
he does not see (and in most cases should not be aware of) the
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 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 stat
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 i
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 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 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 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 global
1 - 100 of 145 matches
Mail list logo
