Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #5934
| Path | csiph.com!au2pb.net!feeder.erje.net!1.eu.feeder.erje.net!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 02:44:11 +0200 |
| Organization | albasani.net |
| Lines | 44 |
| Message-ID | <20151022024411.5dd9275c@maxa-pc> (permalink) |
| References | <n099da$p0g$1@dont-email.me> <n099vp$qho$1@dont-email.me> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=US-ASCII |
| Content-Transfer-Encoding | 7bit |
| X-Trace | news.albasani.net lVxlmGwUtsyfd6F2TQAxG04unopo1qF+SM9o+70qgRzZ2wt9g6gfSVrvENjAmEMrX7Pkn0sQ/UkMtmbJkufE1w== |
| NNTP-Posting-Date | Thu, 22 Oct 2015 00:44:11 +0000 (UTC) |
| Injection-Info | news.albasani.net; logging-data="XK6zJaMP4KzzvB87d3MrGwdJYoLFVpBjjGwTP6KAVVlN8+oHf6K6pyQ7X3YjIr8UF095dKgnF/AqPvbY5JrRlYtb4H0pcGb0d4ETCEaC2RH5r9tWs+IK3dMFGhYoDpnK"; 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:A//fcF57X5D+8wGPQunnbywSjCg= |
| Xref | csiph.com comp.programming:5934 |
Show key headers only | View raw
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.
Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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