<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Fri, 25 May 2012 12:11:24 -0700 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Comments Feed</title>
    <link>http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>By nightelf1984</title>
      <description><![CDATA[ How to avoid delete the same address more than once. For example:
Normally:
int* ptr = (int*)malloc(sizeof(int));
1. free ptr;
2. free ptr;
This will cause system crash if ptr = NULL is not done before step 2. -> at
a reminder for telling coder the program's wrong.

How miser allocator assure the same behavior as the above shows? It seems 'ptr'
will be added to superblock's free list multiple times, isn't it? ]]></description>
      <link>http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-38614</link>
      <pubDate>Wed, 27 Jan 2010 21:10:24 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-38614</guid>
    </item>
    <item>
      <title>By barry.cilk@gmail.com</title>
      <description><![CDATA[ There are many tools available to help you track down memory errors.  For example, Purify from IBM or BoundsChecker from Micro Focus.  I'm sure there are lots of others out there.

Miser assumes that you have a correct application.  It's goal is to provide a fast memory allocator for multithreaded applications.  It makes no attempt to handle a double free gracefully.  It may crash.  It may get stuck in an infinite loop.  There's an infinite number of ways that a buggy program can corrupt memory, and we didn't attempt to make Miser survive them.

     - Barry ]]></description>
      <link>http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-38631</link>
      <pubDate>Thu, 28 Jan 2010 06:23:02 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-38631</guid>
    </item>
    <item>
      <title>By nightelf1984</title>
      <description><![CDATA[ Thanks very much for your remark~ ]]></description>
      <link>http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-38639</link>
      <pubDate>Thu, 28 Jan 2010 23:33:07 -0800</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-38639</guid>
    </item>
    <item>
      <title>By Thomas Willhalm (Intel)</title>
      <description><![CDATA[ Barry,

Any idea how this compares against the scalabale allocator that is included in the Intel Threading Building Blocks library (TBB)? I know that the concept of the TBB allocator is much closer to tcmalloc than miser, but a performance comparison might nevertheless be interesting.

Kind regards
Thomas ]]></description>
      <link>http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-42852</link>
      <pubDate>Mon, 03 May 2010 06:19:40 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/miser-a-dynamically-loadable-memory-allocator-for-multi-threaded-applications/#comment-42852</guid>
    </item>
  </channel></rss>
