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


Groups > comp.arch > #6284

Malloc and transactional memory (TM)

Message-ID <4F56ECEC.8060800@SPAM.comp-arch.net> (permalink)
Date 2012-03-06 21:06 -0800
From "Andy (Super) Glew" <andy@SPAM.comp-arch.net>
Organization comp-arch.net
Newsgroups comp.arch
Subject Malloc and transactional memory (TM)

Show all headers | View raw


http://semipublic.comp-arch.net/wiki/Transactional_memory_and_malloc


Dynamic memory allocation such as malloc is a classic example of why one 
may want memory accesses that can leave a transaxction.

Consider a simple mallocator, that allocates from a single queue or arena.
This might mean that multiple transactions, otherwise completely independent
might appear to interfere with each other through malloc.

(This interference might take several forms.
E.g. if the transactions are first performed totally independently, they 
may allocate the same memory.
E.g. or if the transactions malloc separate areas, but sequentially 
dependent, rollback of one might require rollback of the other.
(Although even this is an advanced TM topic, if the footprints overlap.))

Certainly, there can be malloc algorithms that minimize this - e.g. 
multiple areas, increasing the chance that different transactions might 
not interfere.

Or... the topic of this page:  permit malloc to exit the transaction
- so the [[parallel or concurrent]] mallocs may be properly 
synchronized, and receive independent memory addresses.

Q: what happens when a transaction aborts?
* Possibly could free the memory in the abort handler.  But this becomes 
less hardware, and more software TM.  Or at least a hybrid.
* Let garbage collection recover the memory speculative allocated within 
an aborted transaction.

(Q: what about [[deterministic finalization and aborted transactions]]?)


= Related Topics =

* [[speculative multithreading and memory allocation]]:
** [[malloc and speculative multithreading]]
** [[stack allocation and speculative multithreading]]

Back to comp.arch | Previous | NextNext in thread | Find similar | Unroll thread


Thread

Malloc and transactional memory (TM) "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-06 21:06 -0800
  Re: Malloc and transactional memory (TM) MitchAlsup <MitchAlsup@aol.com> - 2012-03-07 09:54 -0800
    Re: Malloc and transactional memory (TM) "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-03-09 11:20 -0800
  Re: Malloc and transactional memory (TM) George Neuner <gneuner2@comcast.net> - 2012-03-07 14:55 -0500
    Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-07 21:10 +0000
      Re: Malloc and transactional memory (TM) George Neuner <gneuner2@comcast.net> - 2012-03-08 14:23 -0500
        Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-08 19:58 +0000
          Re: Malloc and transactional memory (TM) George Neuner <gneuner2@comcast.net> - 2012-03-10 16:05 -0500
            Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-13 08:39 +0000
    Re: Malloc and transactional memory (TM) "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-07 22:49 -0800
      Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-08 08:02 +0000
        Re: Malloc and transactional memory (TM) "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-08 07:20 -0800
          Re: Malloc and transactional memory (TM) nmm1@cam.ac.uk - 2012-03-08 16:25 +0000
            Re: Malloc and transactional memory (TM) MitchAlsup <MitchAlsup@aol.com> - 2012-03-11 09:27 -0700

csiph-web