Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #5933 > unrolled thread

Re: About transactional memory

Started byRichard Heathfield <rjh@cpax.org.uk>
First post2015-10-22 01:20 +0100
Last post2015-10-22 04:00 +0200
Articles 4 — 2 participants

Back to article view | Back to comp.programming

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: About transactional memory Richard Heathfield <rjh@cpax.org.uk> - 2015-10-22 01:20 +0100
    Re: About transactional memory Melzzzzz <mel@zzzzz.com> - 2015-10-22 02:44 +0200
      Re: About transactional memory Richard Heathfield <rjh@cpax.org.uk> - 2015-10-22 02:51 +0100
        Re: About transactional memory Melzzzzz <mel@zzzzz.com> - 2015-10-22 04:00 +0200

#5933 — Re: About transactional memory

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-10-22 01:20 +0100
SubjectRe: About transactional memory
Message-ID<n099vp$qho$1@dont-email.me>
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

[toc] | [next] | [standalone]


#5934

FromMelzzzzz <mel@zzzzz.com>
Date2015-10-22 02:44 +0200
Message-ID<20151022024411.5dd9275c@maxa-pc>
In reply to#5933
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.

[toc] | [prev] | [next] | [standalone]


#5935

FromRichard Heathfield <rjh@cpax.org.uk>
Date2015-10-22 02:51 +0100
Message-ID<n09fbe$7kk$1@dont-email.me>
In reply to#5934
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

[toc] | [prev] | [next] | [standalone]


#5936

FromMelzzzzz <mel@zzzzz.com>
Date2015-10-22 04:00 +0200
Message-ID<20151022040050.58c2aecf@maxa-pc>
In reply to#5935
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

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming


csiph-web