Just updated to see if the problem would be gone.
[crtl+space] will cause error message like :
C:\lazarus\lcl\lclclasses.pp(32,10) Error: unit not found: Classes
(now to the even the different unit) and the focus goes at the the uses
clause.
Could this be related to some setting, or is
Hello,
If I update my Lazarus from the SVN and then make it, I have slight
problems, which now I correct by hand.
Basically it is like this.
If the last project contains components that Make did not compile for
me, I need to open or make new clean project (and abort the loading of
the
On Monday 27 of June 2011 22:01:46 Krzysztof wrote:
I have empty revision in about, but filename is
lazarus-0.9.31.31388-20110626.i386.deb.tar, downloaded yesterday. I
temporary try create debs from svn which I have on ubuntu and copy them to
kubuntu virtual mashine
BTW: I have two
On 27-06-11 15:19, Hans-Peter Diettrich wrote:
Koenraad Lelong schrieb:
opening the project I have the program-source containing the
startup-code which includes {$I CygnusTest.lrs}.
When I go to Program Options and just click OK that line disappears.
Compiling then fails.
Perhaps you should
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
2011/6/28 zeljko zel...@holobit.net
No, libQt4Pas must be installed , it's glue (C library) between lazarus and
qt libs.
Is any way to compile source of libQt4Pas inside executable? Why GTK and
other interfaces don't need any glue?
--
___
Lazarus
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
34 matches
Mail list logo
