I think we all could need a good lockfree datastructure library for
Freepascal.
Our current implementation is not suitable as it don't cares for
multiplatform, and
64 Bit architectures and is too tightly bound with our internals.
But if someone is interested, we could work together to make some
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
Florian Klaempfl wrote:
> Michael Schnell schrieb:
>>
>
> The point is, it simply affects all processor. Its much better than
> an entercriticalsection but it is not only twice the time of a simply
> inc or whatever.
I want two give my two cent's too.
In the last 4 years, we developed a billing
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 a
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_ FUT
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 l
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
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 o
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
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 synchron
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 acqui
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 - [email protected]
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
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
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 ti
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
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, e
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,
befo
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, before
doing the increment
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, on
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
0x7fff
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 deq
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 acce
23 matches
Mail list logo
