Very interesting stuff indeed !
In your case of course my idea of using something similar to FUTEX
supposedly will not help much, as it would prevent unnecessary system
calls done by semaphore handlers like TCriticalSection and thus reduce
the overhead, but will not cure things like priority
Michael Schnell pisze:
I have to think a bit more about the locking mechanism you suggest.
I;ve added some links on my site
I intended to use a single word as a semaphore to protect the access
to the structure and fall back to an OS-based wait (e.g. by
TCriticalSection) if it can't be
FUTEX is based on atomic operation, the same as I used.
but with lockfree algorithms You don't protect access at all.
I understand this, but I'm nut sure that this really is advantageous.
Any atomic operation in a multicore system with a cache for each core
imposes a delay for cache
Michael Schnell pisze:
FUTEX is based on atomic operation, the same as I used.
but with lockfree algorithms You don't protect access at all.
I understand this, but I'm nut sure that this really is advantageous.
Any atomic operation in a multicore system with a cache for each core
imposes a
Florian Klaempfl pisze:
DarekM schrieb:
Florian Klaempfl pisze:
An if is unimportant, more important is the number of locked operations,
especially on multi core systems they might eat hundreds of clock cycles.
There are atomic operations, the should not eat much more than
Dariusz Mazur wrote:
Florian Klaempfl pisze:
DarekM schrieb:
Florian Klaempfl pisze:
An if is unimportant, more important is the number of locked
operations,
especially on multi core systems they might eat hundreds of clock
cycles.
There are atomic operations, the should not
Any implementation of thread synchronization need care of cache.
FUTEX, which rely on atomic primitives can't be faster than primitives
alone.
I said that (using locking instructions to implement a semaphore) I
might implement something that works similar to FUTEX. I don't intend to
_use_
We don't need wait to synchronize caches. It will be done by hardware.
Right. but waiting performed by the hardware does not take less long
than waiting performed by software :-) .
And i think synchronize cache with ram don't eat hundreads clock cycles.
In all cashed that contain the memory
Michael Schnell schrieb:
We don't need wait to synchronize caches. It will be done by hardware.
Right. but waiting performed by the hardware does not take less long
than waiting performed by software :-) .
And i think synchronize cache with ram don't eat hundreads clock cycles.
In all
I just finished a unit that provides a FIFO and similar stuff, so I'm
very interested.
IMHO you should not use push and put as this suggests a LiFo
(Stack). With my unit I mostly intended to recreate the putc() and
getc() functions in glibc (though I did neither use them nor took a look
at
Some Typos:
It has putc() and getc() (with the same parameters (Integer!) as it's
done in glibc), plus ungetc() and unputc() for reverse operations (which
in fact implements LiFo Stack behavior).
-Michael
___
fpc-devel maillist -
Micha Nelissen pisze:
DarekM wrote:
Hi
This is my proposition of algorithm and its implementing multithreaded
FIFO queue without lock.
Hmm 'Push' and 'Pop' sound like a stack, but the implementation seems to
implement a FIFO indeed, with a head and tail.
It should be enqueue and
DarekM wrote:
Hi
This is my proposition of algorithm and its implementing multithreaded
FIFO queue without lock.
Hmm 'Push' and 'Pop' sound like a stack, but the implementation seems to
implement a FIFO indeed, with a head and tail.
You're sure about the situation where two threads are
What about a long running (eg daemon) application?
If temp/tail hits the upper boundary of Integer?
(If I understand it correctly)
I don't know if interlockedIncrement gives a boundary error, but if not,
it still fails.
- With currently integer, it gets a negative value, once crossing
Martin Friebe pisze:
What about a long running (eg daemon) application?
If temp/tail hits the upper boundary of Integer?
(If I understand it correctly)
I don't know if interlockedIncrement gives a boundary error, but if not,
it still fails.
- With currently integer, it gets a negative value,
Martin Friebe pisze:
You will need to test it, but the following may also work
procedure tFlQueue.push(const tm : tNodeQueue);
var
newTemp,
lastTail,
newTail : integer;
begin
newTemp := temp;
while newTemp = fsize begin
// if it is true, every thread is going to attempt to fix it,
DarekM schrieb:
Martin Friebe pisze:
You will need to test it, but the following may also work
procedure tFlQueue.push(const tm : tNodeQueue);
var
newTemp,
lastTail,
newTail : integer;
begin
newTemp := temp;
while newTemp = fsize begin
// if it is true, every thread is going to
While watching this thread, I started to ask myself 2 questions (which
may be related):
They just came to mind a multi-core systems where mentioned, possible
even systems with several CPUs.
(Admiringly they are more looking like they should be on an
intel-mailing list, I just hope someone may
Florian Klaempfl pisze:
An if is unimportant, more important is the number of locked operations,
especially on multi core systems they might eat hundreds of clock cycles.
There are atomic operations, the should not eat much more than ordinal
INC or ADD,
and second CAS is invoked only one
DarekM schrieb:
Florian Klaempfl pisze:
An if is unimportant, more important is the number of locked operations,
especially on multi core systems they might eat hundreds of clock cycles.
There are atomic operations, the should not eat much more than ordinal
INC or ADD,
If course they
20 matches
Mail list logo
