Re: About transactional memory

Path	csiph.com!eternal-september.org!feeder.eternal-september.org!news.albasani.net!.POSTED!not-for-mail
From	Melzzzzz <mel@zzzzz.com>
Newsgroups	comp.programming
Subject	Re: About transactional memory
Date	Thu, 22 Oct 2015 04:00:50 +0200
Organization	albasani.net
Lines	58
Message-ID	<20151022040050.58c2aecf@maxa-pc> (permalink)
References	<n099da$p0g$1@dont-email.me> <n099vp$qho$1@dont-email.me> <20151022024411.5dd9275c@maxa-pc> <n09fbe$7kk$1@dont-email.me>
Mime-Version	1.0
Content-Type	text/plain; charset=US-ASCII
Content-Transfer-Encoding	7bit
X-Trace	news.albasani.net 2gKYcUKcEr0r6EXeMyoVj+vEEa2/pETr4855Fa6jcS7tj+H3hRQx5XN3JsS8Bz05D//bl5JN1naIGm6pCbA43w==
NNTP-Posting-Date	Thu, 22 Oct 2015 02:00:50 +0000 (UTC)
Injection-Info	news.albasani.net; logging-data="zRuU0RQQvZHN6AyBc7J18z0nAlPib4WvQAZLJAefpO2ie62+03ZhhQZzq0TBtmeY7SGybyz7vU/1HIVrwTu1TspH6wzoYgY3ExrhKqv/DsKFOAB77AAWNab7KHQ9INI3"; mail-complaints-to="abuse@albasani.net"
X-Newsreader	Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-unknown-linux-gnu)
Cancel-Lock	sha1:oH+9xtDpGXQ7MbpgSvmDU577xLY=
Xref	csiph.com comp.programming:5936

Show key headers only | View raw

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

Back to comp.programming | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web