Am 08.02.2013 13:32, schrieb Marco van de Voort:
In our previous episode, Graeme Geldenhuys said:
On 2013-02-07 17:55, Fl?vio Etrusco wrote:
Not if you want high performance and multi-processor support.
I'll prefer _working_ code to start. Currently semaphores are broken in
FPC+FreeBSD. My
On 07 Feb 2013, at 16:52, Ewald wrote:
Altough I still
don't see how you can make these calls atomic then (without the
barrier)?
On x86, it is impossible to perform an atomic access without a
(partial) memory barrier that affects all memory (due to the behaviour
of the lock prefix). On
Once upon a time, on 02/08/2013 04:02 PM to be precise, Jonas Maebe said:
On 07 Feb 2013, at 16:52, Ewald wrote:
Altough I still
don't see how you can make these calls atomic then (without the
barrier)?
On x86, it is impossible to perform an atomic access without a
(partial) memory
Am 08.02.2013 16:02, schrieb Jonas Maebe:
On 07 Feb 2013, at 16:52, Ewald wrote:
Altough I still
don't see how you can make these calls atomic then (without the
barrier)?
On x86, it is impossible to perform an atomic access without a (partial)
memory barrier that affects all memory
On 08 Feb 2013, at 19:06, Florian Klämpfl wrote:
Am 08.02.2013 16:02, schrieb Jonas Maebe:
On 07 Feb 2013, at 16:52, Ewald wrote:
Altough I still
don't see how you can make these calls atomic then (without the
barrier)?
On x86, it is impossible to perform an atomic access without a
On 2013-02-06 20:10, Sven Barth wrote:
We don't have semaphores yet in SyncObjs.
Correct. FPC's SyncObjs unit has quite a few missing features compared
to Delphi.
http://docwiki.embarcadero.com/Libraries/XE2/en/System.SyncObjs
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform
On 2013-02-06 20:17, Sven Barth wrote:
If you just define your own semaphore class that contains the platform
specific types and lock and unlock methods then you only need to add an
additional array[0..4] of Longint after the sem_t field for FreeBSD.
Then you should be okay.
Yes that will
Am 07.02.2013 09:41, schrieb Graeme Geldenhuys:
On 2013-02-06 20:10, Sven Barth wrote:
We don't have semaphores yet in SyncObjs.
Correct. FPC's SyncObjs unit has quite a few missing features compared
to Delphi.
http://docwiki.embarcadero.com/Libraries/XE2/en/System.SyncObjs
Yes, I noticed
Am 07.02.2013 09:46, schrieb Graeme Geldenhuys:
On 2013-02-06 20:17, Sven Barth wrote:
If you just define your own semaphore class that contains the platform
specific types and lock and unlock methods then you only need to add an
additional array[0..4] of Longint after the sem_t field for
On 2013-02-07 09:13, Sven Barth wrote:
But the ifdefs will only be in one location.
I understand that, but there will be IFDEF's none the less. As I said, I
hate IFDEF's in application/library code. They have their place in FPC
source code, but I don't like them anywhere else. That's just me.
Hi Jonas,
Interesting, there is no mention of those limitations in the FPC 2.6.0
documentation. I looked in the RTL docs. It this is a concern, it is
something that should be mentioned in the docs.
Do you know more specifically what platforms or CPU's are affected, so
Michael could update the
On 07 Feb 2013, at 12:27, Graeme Geldenhuys wrote:
Interesting, there is no mention of those limitations in the FPC 2.6.0
documentation. I looked in the RTL docs. It this is a concern, it is
something that should be mentioned in the docs.
That has nothing to do with the programming
On 07 Feb 2013, at 12:52, Jonas Maebe wrote:
It doesn't belong in our manuals. Anyone who wants to manually
create low level thread synchronisation primitives will have to know
a lot more about cpu architecture and memory consistency models then
we could ever describe in our
Once upon a time, on 02/07/2013 11:57 AM to be precise, Jonas Maebe said:
On 06 Feb 2013, at 23:16, Ewald wrote:
Concerning the locking mechanism, you can uses mutex(en/es/ii) or you
can do this by a busy waiting loop with an integer (of course there are
other possibilities). To elaborate on
On 07 Feb 2013, at 13:39, Ewald wrote:
Well, I always thought that the InterLoackedCompareExchange boiles
down
to [**]
.Lock CMPXCHG
Or something quite like that. The `.Lock` there is the important part
since this does insure a memory barier.
It's only a memory barrier if you don't use
Once upon a time, on 02/07/2013 01:46 PM to be precise, Jonas Maebe said:
On 07 Feb 2013, at 13:39, Ewald wrote:
Well, I always thought that the InterLoackedCompareExchange boiles down
to [**]
.Lock CMPXCHG
Or something quite like that. The `.Lock` there is the important part
since this
On Thu, Feb 07, 2013 at 01:01:47PM +0100, Jonas Maebe wrote:
On 07 Feb 2013, at 12:52, Jonas Maebe wrote:
It doesn't belong in our manuals. Anyone who wants to manually
create low level thread synchronisation primitives will have to
know a lot more about cpu architecture and memory
On 07 Feb 2013, at 14:29, Ewald wrote:
Once upon a time, on 02/07/2013 01:46 PM to be precise, Jonas Maebe
said:
On 07 Feb 2013, at 13:39, Ewald wrote:
Well, I always thought that the InterLoackedCompareExchange boiles
down
to [**]
.Lock CMPXCHG
Or something quite like that. The
On Thu, Feb 07, 2013 at 03:11:00PM +0100, Jonas Maebe wrote:
The interlocked* routines only guarantee that that particular value
is updated in atomic way across multiple cores. It does not
guarantee anything about memory access performed before or after
that interlocked* call. The memory
On Thu, Feb 07, 2013 at 02:43:11PM +, Henry Vermaak wrote:
On Thu, Feb 07, 2013 at 03:11:00PM +0100, Jonas Maebe wrote:
The interlocked* routines only guarantee that that particular value
is updated in atomic way across multiple cores. It does not
guarantee anything about memory access
Once upon a time, on 02/07/2013 03:11 PM to be precise, Jonas Maebe said:
The interlocked* routines only guarantee that that particular value is
updated in atomic way across multiple cores. It does not guarantee
anything about memory access performed before or after that
interlocked* call. The
On 2013-02-07 17:55, Flávio Etrusco wrote:
Not if you want high performance and multi-processor support.
I'll prefer _working_ code to start. Currently semaphores are broken in
FPC+FreeBSD. My implementation at least works everywhere I have tested -
without hacks or jumping through loops.
Hi,
OK, now that we established that semaphores are broken in FreeBSD using
FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative.
An alternative for two reasons.
- I hate IFDEF code, and the semaphore code between Linux, FreeBSD
and Windows are different.
- Semaphore
In our previous episode, Graeme Geldenhuys said:
OK, now that we established that semaphores are broken in FreeBSD using
FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative.
An alternative for two reasons.
- I hate IFDEF code, and the semaphore code between Linux, FreeBSD
Am 06.02.2013 20:43 schrieb Marco van de Voort mar...@stack.nl:
In our previous episode, Graeme Geldenhuys said:
OK, now that we established that semaphores are broken in FreeBSD using
FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative.
An alternative for two reasons.
Am 06.02.2013 20:24 schrieb Graeme Geldenhuys gra...@geldenhuys.co.uk:
Hi,
OK, now that we established that semaphores are broken in FreeBSD using
FPC 2.6.0 and the upcoming FPC 2.6.2. I'm looking for an alternative.
An alternative for two reasons.
- I hate IFDEF code, and the semaphore
Hello,
You can use some structure to lock an integer. `Some structure` can for
example be a mutex, a critical section, some busy waiting loop based on
CMPXCH, etc... Say that you lock the integer by calling `Lock;` and you
unlock it by calling `UnLock;`. Then you can define a class TSemaphore
On Wednesday 06 February 2013 20:24:34 Graeme Geldenhuys wrote:
It case I'm overlooking something critical, has anybody else done
something like this. If so, anybody willing to share that code - saving
me some time in developing, unit testing and debugging my own Object
Pascal based
Hi,
I found another problem with Semaphores between FreeBSD and Linux.
Attached is my test project. Again, it is similar code used in tiOPF.
For some reason under FreeBSD, it *always* zeros the variable that holds
the Max Pool Size value passed in to sem_init()'s third parameter. This
means
Am 04.02.2013 12:47, schrieb Graeme Geldenhuys:
Hi,
I found another problem with Semaphores between FreeBSD and Linux.
Attached is my test project. Again, it is similar code used in tiOPF.
For some reason under FreeBSD, it *always* zeros the variable that holds
the Max Pool Size value passed
On Mon, Feb 04, 2013 at 11:47:48AM +, Graeme Geldenhuys wrote:
Hi,
I found another problem with Semaphores between FreeBSD and Linux.
Attached is my test project. Again, it is similar code used in tiOPF.
For some reason under FreeBSD, it *always* zeros the variable that holds
the
On 2013-02-04 12:22, Sven Barth wrote:
I have an idea. But for this I'd need some confirmation: Can you please
put in your example program the FSemaphore into a record and add also a
...
OK, attached is the new test project. Below is the output.
Now the FMaxPoolSize variable still has the
Am 04.02.2013 14:03, schrieb Graeme Geldenhuys:
On 2013-02-04 12:22, Sven Barth wrote:
I have an idea. But for this I'd need some confirmation: Can you please
put in your example program the FSemaphore into a record and add also a
...
OK, attached is the new test project. Below is the output.
Am 04.02.2013 13:40, schrieb Henry Vermaak:
On Mon, Feb 04, 2013 at 11:47:48AM +, Graeme Geldenhuys wrote:
Hi,
I found another problem with Semaphores between FreeBSD and Linux.
Attached is my test project. Again, it is similar code used in tiOPF.
For some reason under FreeBSD, it
On Mon, Feb 04, 2013 at 02:54:10PM +0100, Sven Barth wrote:
Am 04.02.2013 13:40, schrieb Henry Vermaak:
On Mon, Feb 04, 2013 at 11:47:48AM +, Graeme Geldenhuys wrote:
Hi,
I found another problem with Semaphores between FreeBSD and Linux.
Attached is my test project. Again, it is
In our previous episode, Henry Vermaak said:
=== code begin ===
sem_t_rec = record end;
sem_t = ^sem_t_rec;
=== code end ===
Indeed, but trunk pthread.inc looks different from this:
sem_t = record
magic : cuint32;
lock: pthread_mutex_t;
gtzero :
Am 04.02.2013 15:02, schrieb Henry Vermaak:
On Mon, Feb 04, 2013 at 02:54:10PM +0100, Sven Barth wrote:
Am 04.02.2013 13:40, schrieb Henry Vermaak:
On Mon, Feb 04, 2013 at 11:47:48AM +, Graeme Geldenhuys wrote:
Hi,
I found another problem with Semaphores between FreeBSD and Linux.
37 matches
Mail list logo
