>
> Thanks, I will try.
> BTW, what that mean DEBUG=1? Is it exists =2, =3, etc?
AFAIK no.
>> 2) Did you try running make inside the dir with debug then running the
>> normal compile&install procedure?
>
> No, I didn't because I didn't know this procedure.
>
>> AFAICT fpc-pascal was ok (if not be
2011/6/28 Flávio Etrusco
>
> On Tue, Jun 28, 2011 at 9:23 AM, Marcos Douglas wrote:
> > Hi,
> >
> > I compile FPC with success using my tutorial:
> > http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29
> >
> > Questions:
> > 1- How
On Tue, Jun 28, 2011 at 9:23 AM, Marcos Douglas wrote:
> Hi,
>
> I compile FPC with success using my tutorial:
> http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29
>
> Questions:
> 1- How can I compile all packages with DEBUG option
On Tue, 28 Jun 2011 23:29:52 +0200, Hans-Peter Diettrich
wrote:
Vinzent Höfler schrieb:
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 other (as in "older") values.
Andrew Brunner schrieb:
On Tue, Jun 28, 2011 at 9:33 AM, Michael Schnell wrote:
And this has been discussed in the other message: If the variable in fact is
global the compiler needs to avoid caching it, if it is static and the
function is in another module it might still decide to cache it, b
Vinzent Höfler schrieb:
On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell
wrote:
But if you do the same with
volatile static int x;
the code will stay and another thread can watch x growing in a time
sharing system.
No, it can't. "volatile" just ensures that accessing the variable
res
Andrew Brunner schrieb:
On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell wrote:
On 06/28/2011 04:31 PM, Andrew Brunner wrote:
how developers
can force code execution in order w/o using a third party library?
Execution in order only makes sense when there is another thread that relies
on this
28.06.2011 22:38, Vinzent Höfler wrote:
involving some mutex. Such proper constructs are not enforced by
pascal language automatically (like say in java), so mistakes are
quite possible (and sometimes do happen).
JFTR, but they aren't /enforced/ in Java, neither.
Well, ok, I didn't mean that "s
At beginning of June I've found the following link on the ReactOS
mailing list when they were discussing about memory ordering and
volatile as well:
http://kernel.org/doc/Documentation/volatile-considered-harmful.txt
For those interested the following is the link to the starting
discussion:
On Tue, 28 Jun 2011 20:34:19 +0200, Nikolai Zhubr
wrote:
involving some mutex. Such proper constructs are not enforced by pascal
language automatically (like say in java), so mistakes are quite
possible (and sometimes do happen).
JFTR, but they aren't /enforced/ in Java, neither.
Vinze
On Tue, 28 Jun 2011 18:11:29 +0200, Hans-Peter Diettrich
wrote:
I think that you should give at least an example, where instruction
reordering makes a difference. Neither a compiler nor a processor is
allowed to reorder instructions in a way, that breaks the def/use
(produce/consume...)
On Tue, 28 Jun 2011 20:09:18 +0200, 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. All
code executed in between such two calls is absolutely ignorant of the
state of
28.06.2011 19:42, Hans-Peter Diettrich wrote:
Jonas Maebe schrieb:
2.) Blocking access as described in 4.11 does not address execution
order.
It does guarantee that if T1 locks the mutex, changes the value,
unlocks the mutex [...]
Can you explain please, to what "changes the value" applies?
Michael Schnell schrieb:
Only the ordering decision "inside" vs "outside" of the critical section
is necessary for threaded user application. If both Enter and Leave do a
"full fence" barrier, I suppose we are safe.
Since the condition is only stored *inside* the CS or mutex, no other
code w
Andrew Brunner schrieb:
On Tue, Jun 28, 2011 at 9:23 AM, Jonas Maebe wrote:
On topic, Jonas can you take a few moments to describe how developers
can force code execution in order w/o using a third party library? Is
there a compiler directive we can use?
I think that you should give at least
Jonas Maebe schrieb:
2.) Blocking access as described in 4.11 does not address execution
order.
It does guarantee that if T1 locks the mutex, changes the value, unlocks
the mutex [...]
Can you explain please, to what "changes the value" applies?
I could not find a definition of the mutex s
On Tue, 28 Jun 2011 15:20:22 +0200, Andrew Brunner
wrote:
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe
wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
application level -
On Tue, 28 Jun 2011 15:54:35 +0200, Michael Schnell
wrote:
But if you do the same with
volatile static int x;
the code will stay and another thread can watch x growing in a time
sharing system.
No, it can't. "volatile" just ensures that accessing the variable results
in
actual memory
On Tue, Jun 28, 2011 at 10:17 AM, Michael Schnell wrote:
> You still did not give an example
Don't take my word. Just look at the wikipedia link I already posted
which indicates otherwise.
>> Remember ***cores!=threads*** people.
>
> Wrong regarding the issue in question (see the message by J
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!
> User programs are not supposed to bother about anything beyond threads t
On 06/28/2011 05:02 PM, Andrew Brunner wrote:
Wrong. Sigh... Order of execution is paramount just about everywhere.
It can be disastrous if not understood.
You still did not give an example
Remember ***cores!=threads*** people.
Wrong regarding the issue in question (see the message by Jona
On 06/28/2011 04:38 PM, Andrew Brunner wrote:
1.) How can we get the core to not relent and have the code handed off
to another core until we're finished?
2.) How can we get the core to have a synchronised copy of a
particular variable (aside from CAS)?
I suppose you need to ask these questions
On Tue, Jun 28, 2011 at 9:43 AM, Michael Schnell wrote:
> On 06/28/2011 04:31 PM, Andrew Brunner wrote:
>>
>> how developers
>> can force code execution in order w/o using a third party library?
>
> Execution in order only makes sense when there is another thread that relies
> on this order.
Wro
On 28 Jun 2011, at 16:28, Andrew Brunner wrote:
Jonas already pointed you to it:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
"Applications shall ensure that access to any memory location by
more than
one thread of control (threads or processes) is restr
On Tue, Jun 28, 2011 at 9:33 AM, Michael Schnell wrote:
> And this has been discussed in the other message: If the variable in fact is
> global the compiler needs to avoid caching it, if it is static and the
> function is in another module it might still decide to cache it, but you are
> right: i
On 06/28/2011 04:31 PM, Andrew Brunner wrote:
how developers
can force code execution in order w/o using a third party library?
Execution in order only makes sense when there is another thread that
relies on this order.
So if both threads use the same critical section for accessing all
vari
On Tue, Jun 28, 2011 at 9:23 AM, Jonas Maebe wrote:
On topic, Jonas can you take a few moments to describe how developers
can force code execution in order w/o using a third party library? Is
there a compiler directive we can use?
___
fpc-devel maillis
On 06/28/2011 04:23 PM, Jonas Maebe wrote:
On 28 Jun 2011, at 15:54, Michael Schnell wrote:
I believe that inserting some ptherad_mutex... calls will not force
the compiler to bother about some intermediate values of a non
volatile variable.
You believe wrongly.
As the compiler does not
> Jonas already pointed you to it:
>
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11
>
> "Applications shall ensure that access to any memory location by more than
> one thread of control (threads or processes) is restricted such that no
> thread of control can r
On 28 Jun 2011, at 15:54, Michael Schnell wrote:
static int x;
void play_with_x(void) {
for (i=1; i>0; i--) {
x += 1;
};
x = 0;
};
the compiler will see that x is just defined to be 0 in the end and
optimize out thge complete loop.
But if you do the same with
volatile static
On 28/06/11 15:09, Andrew Brunner wrote:
Of course it is. They issue a hardware memory barrier. This stops the cpu
from reordering operations. How do you think anything using pthreads will
work if they didn't?
Documentation please? If what you are saying is accurate just point
me to the doc
On Tue, Jun 28, 2011 at 9:00 AM, Henry Vermaak 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 still need to prevent the cpu from reordering instructio
Hello FPC,
Tuesday, June 28, 2011, 3:39:29 PM, you wrote:
AB> Sort of right. 6 core system. Core 1 locks code block. Code block
AB> should still use interlocked statements to make memory assignments so
AB> that when Core 1 releases lock - Core 2 can have a real-time image of
AB> variable. Othe
> Of course it is. They issue a hardware memory barrier. This stops the cpu
> from reordering operations. How do you think anything using pthreads will
> work if they didn't?
Documentation please? If what you are saying is accurate just point
me to the documentation?
__
> No, that is impossible. That's the whole point of using libraries such as
> libpthread. They abstract such issues away. Using atomic operations inside
> mutex sections only slows down your program unnecessarily (unless you also
> access the target memory location from code not guarded by that mut
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 still need to prevent the cpu from reordering instructions
with memory barriers. I'm starting to sound like a broken re
On 28/06/11 14:20, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
application level - not system.
1.) Code e
On 06/28/2011 03:23 PM, Andrew Brunner wrote:
There is no problem no need for volatile variables. Compare and Swap
or Interlocked mechanisms will solve any problems.
"volatile" is a directive to the compiler on how to handle a variable.
Variables that are not handled by the compiler but handle
On 06/28/2011 03:23 PM, Andrew Brunner wrote:
Getting developers to
chose the right tool for the job is the key here.
Regarding "normal" user application there is only one option: Posix. Ans
same happily is encapsulated in the RTL/LCL for FPC/Lazarus programmers.
"Advanced" (non-portable) prog
On 06/28/2011 03:16 PM, Jonas Maebe wrote:
The C (or Pascal) compiler has no idea whether or not the global
variable will be accessed by the pthread_mutex_lock()/unlock()
function. As a result, it will never cache it in a register across
function calls, and the call to the mutex function by i
On 28 Jun 2011, at 15:39, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe > wrote:
1.) Code execution on die is not controlled by pthreads
implemention -
as it is unaware at that level.
I have no idea what you mean by this. What would "code execution
off die" be
as o
On Tue, Jun 28, 2011 at 8:28 AM, Jonas Maebe wrote:
>> 1.) Code execution on die is not controlled by pthreads implemention -
>> as it is unaware at that level.
> I have no idea what you mean by this. What would "code execution off die" be
> as opposed to "code execution on die"?
"on die" imag
On 06/28/2011 03:20 PM, Andrew Brunner wrote:
Nothing about order - just access -
As only on thread can be inside one of the code sequences protected by
the CriticalSection, we only need the correct ordering outside vs.
inside of the Critical section. so I suppose access management (Full
Fence
On 28 Jun 2011, at 15:20, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe > wrote:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
(point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
application level - not system.
On 06/28/2011 03:00 PM, Jonas Maebe wrote:
. I don't know about the Windows equivalents.
see
http://msdn.microsoft.com/en-us/library/ms686355%28v=VS.85%29.aspx
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mail
On Tue, Jun 28, 2011 at 8:16 AM, Jonas Maebe wrote:
> The C (or Pascal) compiler has no idea whether or not the global variable
> will be accessed by the pthread_mutex_lock()/unlock() function. As a result,
> it will never cache it in a register across function calls, and the call to
> the mutex f
On Tue, Jun 28, 2011 at 8:11 AM, Jonas Maebe wrote:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html
> (point 4.11)
Nope. Nothing about order - just access - and that is entirely on the
application level - not system.
1.) Code execution on die is not controlled by pthr
On 06/28/2011 02:58 PM, Andrew Brunner wrote:
A mutex may be able to atomically block access because of its own
memory barrier, but I would suggest that employing such a technique on
multi-core systems will not ensure an accurate value.
If this is true, how can any multithreaded be done ?
Only
On 28 Jun 2011, at 14:32, Michael Schnell wrote:
So, regarding C, I understand that (even in a single CPU environment):
If all accesses to a variable are protected by a MUTEX, multiple
threads will use the variable as expected, only if it is defined as
volatile. Otherwise is might be cache
On 28/06/11 14:00, Jonas Maebe wrote:
On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell
wrote:
For variables not defined as volatile, (e.g.) pthread_mutex (and similar
stuff on Windows) can be used to protect them.
A mutex may be able to atom
On 28 Jun 2011, at 15:05, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 8:00 AM, Jonas Maebe > wrote:
On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
A mutex may be able to atomically block access because of its own
memory barrier, but I would suggest that employing such a
technique on
mu
On Tue, Jun 28, 2011 at 8:00 AM, Jonas Maebe wrote:
>
> On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
>
>> On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell
>> wrote:
>>
>>> For variables not defined as volatile, (e.g.) pthread_mutex (and similar
>>> stuff on Windows) can be used to protect them
On 28 Jun 2011, at 14:58, Andrew Brunner wrote:
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell
wrote:
For variables not defined as volatile, (e.g.) pthread_mutex (and
similar
stuff on Windows) can be used to protect them.
A mutex may be able to atomically block access because of its
On Tue, Jun 28, 2011 at 6:14 AM, Michael Schnell wrote:
> For variables not defined as volatile, (e.g.) pthread_mutex (and similar
> stuff on Windows) can be used to protect them.
>
A mutex may be able to atomically block access because of its own
memory barrier, but I would suggest that employi
On 06/28/2011 01:20 PM, Henry Vermaak wrote:
"Operations on volatile variables are not atomic,
That is of course known.
nor do they establish a proper happens-before relationship for threading.
I see. So maybe part of my question is invalid.
But as pthread_mutex (and the appropriate Windows
Hi,
I compile FPC with success using my tutorial:
http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29
Questions:
1- How can I compile all packages with DEBUG option?
2- How can I compile just one package, eg fcl-xml, with DEBUG opti
On 28/06/11 12:14, Michael Schnell wrote:
A similar discussion is going on in Lazarus-develop, but this obviously
is a compiler question.
In C, there is the volatile keyword that ensures that after the code
sequence enters the next C instruction after that which modified this
variable, another
Here is a little idea for an automated check or so, to warn if something odd
is happening or so ;) :):
Assert( SizeOf(byte) = 1, 'SizeOf(byte)(' + IntToStr(SizeOf(byte)) + ') =
1' );
Assert( SizeOf(word) = 2, 'SizeOf(word)(' + IntToStr(SizeOf(word)) + ') =
2' );
Assert( SizeOf(longword) = 4, '
A similar discussion is going on in Lazarus-develop, but this obviously
is a compiler question.
In C, there is the volatile keyword that ensures that after the code
sequence enters the next C instruction after that which modified this
variable, another thread sees the correct state of the var
Hi,
I get a compilation error in the compiler when creating a win32 to
arm-wince crosscompiler with fpc 2.5.1:
cgcpu.pas(2087,88) Error: Identifier not found "pasbool"
Can
http://svn.freepascal.org/cgi-bin/viewvc.cgi/branches/pasboolxx/compiler/arm/cgcpu.pas?r1=17847&r2=17846&pathrev=17847
be me
60 matches
Mail list logo
