[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.programming

About transactional memory

Ramine

10/22/2015 3:12:00 AM


Hello,


I was thinking more and more...

And now i have come to an interesting subject...

Perhaps you will ask me a question as this:

Amine, why have you invented your new scalable distributed reader-writer
mutex, and why have you not simply used transactional memory like: Intel
TSX or others..

Answer:

You have to know that transactional memory is an general purpose
optimistic mechanism, other than that in case of conflicts it can
rollback in a lockfree manner.. so this not good because it can cause
starvation and also it's not energy efficient.

But my new scalable distributed reader-writer mutex can be configured
easily to be starvation-free and to be energy efficient using my
scalable RWLockX that is energy efficient because it doesn't spin-wait
but uses my portable SemaMonitor and portable event objects.

So all in all my scalable distributed reader-writer mutex is still
an interresting synchronisation mechanism to use, and also my new
algorithm of a scalable reader-writer mutex takes care of false-sharing
and it is now sequential consistent and like in Seqlock or RCU , my new
scalable distributed reader-writer mutex doesn't use any atomic
operations and/or StoreLoad style memory barriers on the reader side, so
it's very fast and scalable..but you have to use the define's option
TLW_RWLockX or the define's option TRWLockX inside the defines1.inc file
for that.


You can download it from:

https://sites.google.com/site/aminer68/scalable-distributed-reader-wr...



Thank you for your time.


Amine Moulay Ramdane.
4 Answers

Richard Heathfield

10/22/2015 12:20:00 AM

0

On 22/10/15 04:12, Ramine wrote:
>
> Hello,
>
>
> I was thinking more and more...

Okay, I'll run with that for now.

>
> And now i have come to an interesting subject...
>
> Perhaps you will ask me a question as this:
>
> Amine, why have you invented your new scalable distributed reader-writer
> mutex, and why have you not simply used transactional memory like: Intel
> TSX or others..

Well, no, but I do have a question for you.

This code is from Mlock.pas:

Buffer1 := AllocMem(SizeOf(TListEntry) + Alignment);
FCount1 := PListEntry((int(Buffer1) + Alignment - 1)
and not (Alignment - 1));

I am guessing that AllocMem is rather like malloc, in that it allocates
a bunch of memory. Is AllocMem an implementation-defined function, or
one of yours? If it's one of yours, where is the source code?

If it's not one of yours, what happens if it can't allocate the memory?
Does it return some kind of failure indicator, a la malloc?

If so, why aren't you testing for that, and is all your code this shaky?

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Melzzzzz

10/22/2015 12:44:00 AM

0

On Thu, 22 Oct 2015 01:20:09 +0100
Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 22/10/15 04:12, Ramine wrote:
> >
> > Hello,
> >
> >
> > I was thinking more and more...
>
> Okay, I'll run with that for now.
>
> >
> > And now i have come to an interesting subject...
> >
> > Perhaps you will ask me a question as this:
> >
> > Amine, why have you invented your new scalable distributed
> > reader-writer mutex, and why have you not simply used transactional
> > memory like: Intel TSX or others..
>
> Well, no, but I do have a question for you.
>
> This code is from Mlock.pas:
>
> Buffer1 := AllocMem(SizeOf(TListEntry) + Alignment);
> FCount1 := PListEntry((int(Buffer1) + Alignment - 1)
> and not (Alignment - 1));
>
> I am guessing that AllocMem is rather like malloc, in that it
> allocates a bunch of memory. Is AllocMem an implementation-defined
> function, or one of yours? If it's one of yours, where is the source
> code?
>
> If it's not one of yours, what happens if it can't allocate the
> memory? Does it return some kind of failure indicator, a la malloc?
>
> If so, why aren't you testing for that, and is all your code this
> shaky?
>

It can be configured to either return NULL or throw run time error.
By default it throws error.

Richard Heathfield

10/22/2015 1:52:00 AM

0

On 22/10/15 01:44, Melzzzzz wrote:
> On Thu, 22 Oct 2015 01:20:09 +0100
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> On 22/10/15 04:12, Ramine wrote:
>>>
>>> Hello,
>>>
>>>
>>> I was thinking more and more...
>>
>> Okay, I'll run with that for now.
>>
>>>
>>> And now i have come to an interesting subject...
>>>
>>> Perhaps you will ask me a question as this:
>>>
>>> Amine, why have you invented your new scalable distributed
>>> reader-writer mutex, and why have you not simply used transactional
>>> memory like: Intel TSX or others..
>>
>> Well, no, but I do have a question for you.
>>
>> This code is from Mlock.pas:
>>
>> Buffer1 := AllocMem(SizeOf(TListEntry) + Alignment);
>> FCount1 := PListEntry((int(Buffer1) + Alignment - 1)
>> and not (Alignment - 1));
>>
>> I am guessing that AllocMem is rather like malloc, in that it
>> allocates a bunch of memory. Is AllocMem an implementation-defined
>> function, or one of yours? If it's one of yours, where is the source
>> code?
>>
>> If it's not one of yours, what happens if it can't allocate the
>> memory? Does it return some kind of failure indicator, a la malloc?
>>
>> If so, why aren't you testing for that, and is all your code this
>> shaky?
>>
>
> It can be configured to either return NULL or throw run time error.
> By default it throws error.

Okay, so if there isn't enough memory, either it throws an error, in
which case the program aborts unexpectedly (I see no "catch" code here),
or it scribbles all over memory it doesn't own.

Neither option looks good from over here.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

Melzzzzz

10/22/2015 2:01:00 AM

0

On Thu, 22 Oct 2015 02:51:42 +0100
Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 22/10/15 01:44, Melzzzzz wrote:
> > On Thu, 22 Oct 2015 01:20:09 +0100
> > Richard Heathfield <rjh@cpax.org.uk> wrote:
> >
> >> On 22/10/15 04:12, Ramine wrote:
> >>>
> >>> Hello,
> >>>
> >>>
> >>> I was thinking more and more...
> >>
> >> Okay, I'll run with that for now.
> >>
> >>>
> >>> And now i have come to an interesting subject...
> >>>
> >>> Perhaps you will ask me a question as this:
> >>>
> >>> Amine, why have you invented your new scalable distributed
> >>> reader-writer mutex, and why have you not simply used
> >>> transactional memory like: Intel TSX or others..
> >>
> >> Well, no, but I do have a question for you.
> >>
> >> This code is from Mlock.pas:
> >>
> >> Buffer1 := AllocMem(SizeOf(TListEntry) + Alignment);
> >> FCount1 := PListEntry((int(Buffer1) + Alignment - 1)
> >> and not (Alignment - 1));
> >>
> >> I am guessing that AllocMem is rather like malloc, in that it
> >> allocates a bunch of memory. Is AllocMem an implementation-defined
> >> function, or one of yours? If it's one of yours, where is the
> >> source code?
> >>
> >> If it's not one of yours, what happens if it can't allocate the
> >> memory? Does it return some kind of failure indicator, a la malloc?
> >>
> >> If so, why aren't you testing for that, and is all your code this
> >> shaky?
> >>
> >
> > It can be configured to either return NULL or throw run time error.
> > By default it throws error.
>
> Okay, so if there isn't enough memory, either it throws an error, in
> which case the program aborts unexpectedly (I see no "catch" code
> here), or it scribbles all over memory it doesn't own.
>
> Neither option looks good from over here.
>

What puzzles me most is that global variable which controls function
behavior can be set by user ;p