On 06/28/2011 06:07 PM, Andrew Brunner wrote:
You can stick your head in the sand all you want, just don't run your
code on multi-core cpus and expect valid stability - and come back
here complaining on how unstable your multi-threaded application is
due to FPC design!
If a correctly done Posix
On 06/28/2011 06:33 PM, Andrew Brunner wrote:
Remember ***cores!=threads*** people.
Wrong regarding the issue in question (see the message by Jonas).
I'm at a loss for words. So you equate threads to cores?
A (Posix compliant) user software needs to consider each thread as
running on it's
On 06/28/2011 10:25 PM, Hans-Peter Diettrich wrote:
Can you run your test again, assuring that only one thread can access
the list at the same time, but *without* the Interlocked updates?
This would be a very nice move of Andrew's !!!
If he uses a single TCriticalSection instance to
On 28/06/11 15:15, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 9:00 AM, Henry Vermaakhenry.verm...@gmail.com wrote:
On 28/06/11 14:23, Andrew Brunner wrote:
There is no problem no need for volatile variables. Compare and Swap
or Interlocked mechanisms will solve any problems.
Nope. You
Vinzent Höfler schrieb:
Question is, what makes one variable use read/write-through, while
other variables can be read from the cache, with lazy-write?
Synchronisation. Memory barriers. That's what they are for.
And this doesn't happen out of thin air. How else?
Is this a compiler
On 06/28/2011 06:42 PM, Hans-Peter Diettrich wrote:
I could not find a definition of the mutex struct, to determine
whether it contains any user-alterable values. When the value is
declared outside the mutex struct, it will be accessible also
*without* locking the mutex first.
What do you
29.06.2011 15:28, Hans-Peter Diettrich:
But if so, which variables (class fields...) can ever be treated as
non-volatile, when they can be used from threads other than the main
thread?
Without explicit synchronisation? Actually, none.
Do you understand the implication of your answer?
When
On 06/28/2011 08:09 PM, Hans-Peter Diettrich wrote:
When you have a look at TThreadList.LockList/UnlockList, then you'll
see that LockList enters the critical section, and UnlockList leaves it.
Yep This is how a CS works.
All code executed in between such two calls is absolutely ignorant of
On 06/28/2011 07:05 PM, Vinzent Höfler wrote:
On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell
mschn...@lumino.de wrote:
No, it can't. volatile just ensures that accessing the variable
results in
actual memory accesses. That does not mean cache-coherence, so another
core
may still see
On 06/29/2011 01:06 AM, Vinzent Höfler wrote:
Without explicit synchronisation? Actually, none.
How to do such synchronization with normal portable user-program
programming (aka Posix means).
-Michael
___
fpc-devel maillist -
On 06/29/2011 01:28 PM, Hans-Peter Diettrich wrote:
Do you understand the implication of your answer?
Regarding Objects it would mean that it's forbidden to create an object
in one thread and use it in another one. This is done very often.I can't
believe that the hardware is that bad.
On 28 Jun 2011, at 22:25, Hans-Peter Diettrich wrote:
Andrew Brunner schrieb:
Wrong. Sigh... Order of execution is paramount just about
everywhere.
It can be disastrous if not understood.
Remember ***cores!=threads*** people.
If your experience is really that chaotic, I think it's worth
On 06/29/2011 03:17 PM, Nikolai Zhubr wrote:
All places where any non-readonly data could be accessed by 2 or more
threads should be protected. Thats it.
So this is not supposed to work:
Main thread:
myThread := TmyThread.Create(True);
while not myThread.Suspended sleep(0); //give
Here is a nice example of one that actually works...
http://wiki.lazarus.freepascal.org/Manager_Worker_Threads_System
Granted I wrote this sample and Wiki a long time ago, but you may want
to read this ;-)
___
fpc-devel maillist -
On 06/29/2011 04:33 PM, Andrew Brunner wrote:
Here is a nice example of one that actually works...
http://wiki.lazarus.freepascal.org/Manager_Worker_Threads_System
Nice.
But actually what we need is an example that does not work and shows a
case that the cache incoherency in fact is not
Michael Schnell schrieb:
All code executed in between such two calls is absolutely ignorant of
the state of the CS, there is no in/outside.
The State (relevant to this thread) of CS does not change when some
code of the thread is between enter and leave. So it is not ignorant
but it does
Nikolai Zhubr schrieb:
29.06.2011 15:28, Hans-Peter Diettrich:
But if so, which variables (class fields...) can ever be treated as
non-volatile, when they can be used from threads other than the main
thread?
Without explicit synchronisation? Actually, none.
Do you understand the implication
29.06.2011 18:31, Michael Schnell:
[...]
So this is not supposed to work:
Main thread:
myThread := TmyThread.Create(True);
while not myThread.Suspended sleep(0); //give up time slice to allow the
worker thread to start
myList := TThreadlist.Create; // set the variable in cache 1
On 06/29/2011 05:28 PM, Hans-Peter Diettrich wrote:
The code in a called subroutine doesn't know about the CS. [It usually
also doesn't care about from which exact thread it was called]
This means that possible recursion must be prevented in all related
code in a CS, or (safer) that the CS
On 06/29/2011 05:57 PM, Hans-Peter Diettrich wrote:
This means that a simplified version of TThreadList would be nice,
that allows to wrap a single shareable object and make it usable in an
thread-safe way.
IMHO just TList is OH for this purpose. It (supposedly) is per-instance
thread
29.06.2011 19:57, Hans-Peter Diettrich:
[...]
imply that in detail all application specific
objects must be either local to an thread, or must be protected against
concurrent access (shareable)?
IMHO yes.
[...]
Possibly the language could be extended to help in the determination of
On 06/29/2011 05:29 PM, Nikolai Zhubr wrote:
. I somehow doubt that passing these system calls could let something
remain unflushed in the cache, as the OS will most probably have to do
some synchronization inside these calls for internal bookkeeping, but
this is IMHO kind of side-effect.
On 29 Jun 2011, at 17:29, Nikolai Zhubr wrote:
29.06.2011 18:31, Michael Schnell:
[...]
So this is not supposed to work:
Main thread:
myThread := TmyThread.Create(True);
while not myThread.Suspended sleep(0); //give up time slice to allow the
worker thread to start
sleep(0) does not
On Wed, 29 Jun 2011 16:31:32 +0200, Michael Schnell mschn...@lumino.de
wrote:
On 06/29/2011 03:17 PM, Nikolai Zhubr wrote:
All places where any non-readonly data could be accessed by 2 or more
threads should be protected. Thats it.
So this is not supposed to work:
Precisely, it is not
On Wed, 29 Jun 2011 15:57:15 +0200, Michael Schnell mschn...@lumino.de
wrote:
On 06/29/2011 01:06 AM, Vinzent Höfler wrote:
Without explicit synchronisation? Actually, none.
How to do such synchronization with normal portable user-program
programming (aka Posix means).
POSIX:
On Wed, 29 Jun 2011 13:28:20 +0200, Hans-Peter Diettrich
drdiettri...@aol.com wrote:
Vinzent Höfler schrieb:
Question is, what makes one variable use read/write-through, while
other variables can be read from the cache, with lazy-write?
Synchronisation. Memory barriers. That's what they
26 matches
Mail list logo
