On 06/23/2010 05:35 PM, Daniël Mantione wrote:
It's a non-issue. If you set a thread realtime you know what you are
doing and can take care you give up the CPU when feasible, or you
simply don't enter mutuxes shared with non-realtime threads.
I don't agree.
If the RTL provides a method, it
On 06/23/2010 06:04 PM, Henry Vermaak wrote:
That only means that it doesn't send the lock signal to the external
memory manager, so you can't have a multi processor implementation
using this processor. It doesn't affect the working of the swp
instruction.
I understand the external memory
On 06/23/2010 09:26 PM, Florian Klämpfl wrote:
I'am sure if it's a problem for somebody, he will find a solution and
send a patch.
As the swap instruction seems to be the only atomic memory operation ARM
lower than v6 can do, there is no possible workaround in user space
software.
For a
On 24 Jun 2010, at 09:27, Michael Schnell wrote:
[ARMv5 and lower atomic exchange]
If there is no other way with this arch but an
active spinning lock,
There is indeed none.
the blocked thread should at least give up it's
current time slice before retrying to get the lock, so that the
Michael Schnell schrieb:
On 06/23/2010 05:35 PM, Daniël Mantione wrote:
It's a non-issue. If you set a thread realtime you know what you are
doing and can take care you give up the CPU when feasible, or you
simply don't enter mutuxes shared with non-realtime threads.
I don't agree.
If
Op Thu, 24 Jun 2010, schreef Michael Schnell:
On 06/23/2010 05:35 PM, Daniël Mantione wrote:
It's a non-issue. If you set a thread realtime you know what you are
doing and can take care you give up the CPU when feasible, or you
simply don't enter mutuxes shared with non-realtime threads.
On 06/24/2010 10:02 AM, Florian Klaempfl wrote:
Well, yes, you shouldn't simply use locked operations in a single cpu
environment, your application should provide different algorithms for
single and multi cpu/threaded environments if the application really
contains speed critical code
On 06/24/2010 10:10 AM, Daniël Mantione wrote:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by
the other cpu; you would waste the rest of time slice while you could
be crunching
Of course you are right.
Michael Schnell schrieb:
On 06/24/2010 10:02 AM, Florian Klaempfl wrote:
Well, yes, you shouldn't simply use locked operations in a single cpu
environment, your application should provide different algorithms for
single and multi cpu/threaded environments if the application really
contains
On 24 June 2010 09:00, Michael Schnell mschn...@lumino.de wrote:
On 06/23/2010 09:26 PM, Florian Klämpfl wrote:
I'am sure if it's a problem for somebody, he will find a solution and
send a patch.
As the swap instruction seems to be the only atomic memory operation ARM
lower than v6 can do,
Hi,
Looking at the rtl/unix/cthread.pp unit, I noticed two $Warning lines sayin
that setting or getting thread priority is not implemented for any unix
system. WHAT???
I then thought I would go ahead and do the implementation. Seeing that
cthreads using libc and POSIX implementation, there was
On 06/24/2010 10:23 AM, Florian Klaempfl wrote:
Nobody provided either code yet which makes dynamic use of strex/ldex
as newer arms provide as I did e.g. for move using pld if available
because I needed it.
The code using strex/ldex is in place for ARMv6 and ARMv7. I don't doubt
that same
On 24 June 2010 09:16, Michael Schnell mschn...@lumino.de wrote:
On 06/24/2010 10:10 AM, Daniël Mantione wrote:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by
the other cpu; you would waste the rest of
Op 2010-06-24 11:06, Graeme Geldenhuys het geskryf:
* Dynamic priorities have a range of -20..20
Just to f*ck with you even more, this range is now switched around.
-20 is real-time
0 is normal
20 is idle
And here is why I say it is wrong... rtl/unix/tthread.inc
Michael Schnell schrieb:
On 06/24/2010 10:23 AM, Florian Klaempfl wrote:
Nobody provided either code yet which makes dynamic use of strex/ldex
as newer arms provide as I did e.g. for move using pld if available
because I needed it.
The code using strex/ldex is in place for ARMv6 and
Den Jean schrieb:
On Tuesday 22 June 2010 23:24:28 Florian Klämpfl wrote:
(This is normal on N900, it is called optify, do not know
why /opt/bin is not in path.)
Just insert /opt/bin into the path?
this would mean editing a system file
like /etc/profile, I'd like to avoid that
in
On 06/24/2010 11:05 AM, Henry Vermaak wrote:
/* Atomic compare and exchange. These sequences are not actually atomic;
there is a race if *MEM != OLDVAL and we are preempted between the two
swaps. However, they are very close to atomic, and are the best that a
pre-ARMv6
On 06/24/2010 11:23 AM, Florian Klaempfl wrote:
But it is not used dynamically: if you compile for arm linux, you get
the ARMv5 code path even if the code runs on ARMv6+
I see.
I suppose somewhere you can define that you want RMv6+ code. I would do
this whenever possible.
Maybe providing
On 06/24/2010 11:21 AM, Henry Vermaak wrote:
SMP is not supported by the kernel for arch armv6.
Great !
So nothing serious needs to be done about that. Maybe automatically
detecting the arch and using the best possible code for atomicness would
be a good way to go.
-Michael
On 24 June 2010 10:05, Henry Vermaak henry.verm...@gmail.com wrote:
The linux specific code is here:
http://www.eglibc.org/cgi-bin/viewcvs.cgi/trunk/ports/sysdeps/unix/sysv/linux/arm/nptl/bits/atomic.h?rev=3063view=markup
It relies completely on the kernel.
Which exposes the user helpers
On 06/24/2010 12:23 PM, Henry Vermaak wrote:
Which exposes the user helpers here:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/kernel/entry-armv.S;h=7ee48e7f8f318a7b453e12849b60a6832bb85770;hb=HEAD#l767
Yep.
These are segment of kernel provided
On 06/24/2010 12:17 PM, Michael Schnell wrote:
Maybe automatically
detecting the arch and using the best possible code for atomicness would
be a good way to go.
Even better: as you found the fixed addresses implementations same
should be used having the Kernel automatically provide the
Hi All,
Threads are evil?
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
Interesting view point. Perhaps that is why FPC doesn't bother too much
about thread priorities? :-)
Regards,
Paul.
___
fpc-devel maillist -
Graeme Geldenhuys schrieb:
Looking at the rtl/unix/cthread.pp unit, I noticed two $Warning lines sayin
that setting or getting thread priority is not implemented for any unix
system. WHAT???
I then thought I would go ahead and do the implementation. Seeing that
cthreads using libc and POSIX
Daniël Mantione schrieb:
Yes, but in a multi-cpu system giving up the timeslice is a very bad
idea, because the lock might be released a few clock cycles later by the
other cpu; you would waste the rest of time slice while you could be
crunching.
IMO the default implementation should work
On 24 June 2010 13:44, Hans-Peter Diettrich wrote:
Thus priorities should only be considered as *hints* to the scheduler, with
unpredictable consequences on arbitrary machines. When an application is
So is there a kernel default which applies to most popular Linux
distros? If there is, does
On 24 Jun 2010, at 15:05, Graeme Geldenhuys wrote:
Also does multiple schedulers apply to other non-Linux platforms too?
eg: OSX, FreeBSD, NetBSD, Haiku, etc. Because currently any unix-type
platform doesn't have Thread Priority support in FPC.
The POSIX pthread_setschedparam() api is not
Op 2010-06-24 16:25, Jonas Maebe het geskryf:
The POSIX pthread_setschedparam() api is not really appropriate in
this case. It's mainly geared at real-time threads, which is why POSIX
I also tried to use Google to see if there is any other way of setting
thread priority, and all Google
On 24 Jun 2010, at 16:46, Graeme Geldenhuys wrote:
--[ Kylix 3 Help ]---
Policy Type Priority
--
SCHED_RR Real Time 1-99
SCHED_FIFO Real Time 1-99
Paul van Helden schrieb:
Threads are evil?
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
Interesting view point. Perhaps that is why FPC doesn't bother too much
about thread priorities? :-)
IMO the author neglects the existence of realtime systems, which have to
deal
Due to lack of resources which might have caused some of the repostories
damages, I had to turn off the fpc svn mercurial mirrors. If there is
enough interested, we can look for an alternative machine hosting it.
___
fpc-devel maillist -
On Thursday 24 June 2010 11:37:18 Florian Klaempfl wrote:
is just ppcarm, fpc, fpcmake,fpcres enough ?
Does it hurt to have more?
not technically, as mentioned above I would
prefer not to have to instruct to create too many links.
___
fpc-devel
On Wednesday 23 June 2010 01:49:29 Den Jean wrote:
when trying to compile lazarus using native arm on N900,
I get the errors below. There is no file lazarus.or (strange extension ??)
on i386 the file lazarus.or exists after compilation,
copying it to arm device lazarus svn does not help
33 matches
Mail list logo
