|
|
 Up |
|
|
  |
Author: Chris ThomassonChris Thomasson Date: Apr 23, 2008 23:50
>
> The difference between StreamFlow and ScopeAlloc (or AutoFreeAlloc)
> are:
>
> 1. StreamFlow uses thread local storage, while ScopeAlloc doesn't.
There are benefits for using TLS. Think of a simple contrived scenario like:
void function() {
// I need to allocate from m_alloc...
// How can I do this without adding any parameters?
}
void thread() {
GenericAllocator m_alloc;
function();
}
AFAICT, your allocator can use TLS as-is... Basically, something like:
|
| Show full article (3.56Kb) |
|
| | no comments |
|
|
Author: Chris ThomassonChris Thomasson Date: Apr 25, 2008 01:50
>{ Please do not quote extraneous material, such as the clc++m banner.
> Please also note that top posting is discouraged in this group. -mod }
>
> Yes, GC Allocator is not thread-safe. It's my EMPHASES in
> implementation section. And that is
> why GC Allocator is so fast.
>
> I don't think implementing a producer/consumer pattern is a common
> case. So, why not implement an allocator without a multithreaded lock,
> then use it with a explicit lock when you implement a producer/
> consumer pattern (or something that need to share memory)?
[...]
Well, I use producer/consumer all the time. AFAICT, it is a fairly common
pattern indeed.
|
| |
|
| | no comments |
|
|
Author: xushiweixushiwei Date: Apr 25, 2008 08:51
Hello all,
I add a new class: TlsBlockPool. And now you can define a ScopeAlloc
instance without given parameters:
ScopeAlloc alloc;
It is same as:
ScopeAlloc alloc(TlsBlockPool::instance());
Thank Chris Thomasson for his suggestion.
---
class TlsBlockPool
{
public:
TlsBlockPool() { init(); }
~TlsBlockPool() { term(); }
static void init();
static void term();
static BlockPool& instance();
};
|
| Show full article (0.90Kb) |
| no comments |
|
|
Author: Stephen HoweStephen Howe Date: Apr 25, 2008 08:51
> I don't think implementing a producer/consumer pattern is a common
> case.
Of course it is.
Common producer/consumer patterns are stacks, queues or priority queues -
all in the standard library
Having one or more threads adding elements and one or more different threads
removing elements (thread safe of course) seems normal.
Stephen Howe
|
| |
| no comments |
|
|
Author: xushiweixushiwei Date: Apr 25, 2008 08:51
On Apr 25, 5:42 pm, "Chris Thomasson" comcast.net> wrote:>
> Well, I use producer/consumer all the time. AFAICT, it is a fairly common
> pattern indeed.
>
Yes, and it is same to me. But you only need to implement ONE producer/
consumer pattern, don't you?
|
| |
| no comments |
|
|
Author: xushiweixushiwei Date: Apr 25, 2008 08:51
On Apr 24, 3:43 pm, "Chris Thomasson" comcast.net> wrote:>
> There are benefits for using TLS. Think of a simple contrived scenario like:
>
> void function() {
> // I need to allocate from m_alloc...
> // How can I do this without adding any parameters?
>
> }
>
> void thread() {
> GenericAllocator m_alloc;
> function();
>
> }
>
> AFAICT, your allocator can use TLS as-is... Basically, something like:
>
> void function() {
> GenericAllocator* const pm_alloc = pthread_getspecific(...); ...
|
| Show full article (3.56Kb) |
| no comments |
|
|
Author: xushiweixushiwei Date: Apr 25, 2008 08:52
On Apr 24, 3:43 pm, "Chris Thomasson" comcast.net> wrote:>
> There are benefits for using TLS. Think of a simple contrived scenario like:
>
> void function() {
> // I need to allocate from m_alloc...
> // How can I do this without adding any parameters?
>
> }
>
> void thread() {
> GenericAllocator m_alloc;
> function();
>
> }
>
> AFAICT, your allocator can use TLS as-is... Basically, something like:
>
> void function() {
> GenericAllocator* const pm_alloc = pthread_getspecific(...); ...
|
| Show full article (1.36Kb) |
| no comments |
|
|
Author: Chris ThomassonChris Thomasson Date: Apr 25, 2008 14:27
> On Apr 24, 3:43 pm, "Chris Thomasson" comcast.net> wrote:>>
>> There are benefits for using TLS. Think of a simple contrived scenario
>> like:
>>
>> void function() {
>> // I need to allocate from m_alloc...
>> // How can I do this without adding any parameters?
>>
>> }
>>
>> void thread() {
>> GenericAllocator m_alloc;
>> function();
>>
>> }
>>
>> AFAICT, your allocator can use TLS as-is... Basically, something like: ...
|
| Show full article (1.29Kb) |
| no comments |
|
|
Author: Yongwei WuYongwei Wu Date: Apr 28, 2008 14:00
On Apr 23, 5:22 am, xushiwei gmail.com> wrote:> In fact, "GC Allocator" is NOT "GC".
>
> "GC Allocator" focus:
>
> 1. It is a better "Smart Pointer".
> 2. Deleting objects manually is no need if you use "GC Allocator".
I found it difficult to justify your statement. How do you deallocate
objects, really? You did not explain well in the PDF, and a glance at
the code indicated that you simply do *not* deallocate objects in the
middle of a function. If I did not read wrong, your work is not
suitable in most real-world cases that require a program to run for
more than a short while.
> 3. Use non-static allocator instances to allocate memory instead of
> global new/delete procedures. Then multithreads locks are OPTIONAL and
> you can use explicit locks if you need.
>
> You can consider "GC Allocator" as a "Smart Pointer" or a "Allocator",
> but It isn't a "GC".
|
| Show full article (1.15Kb) |
| no comments |
|
|
|
|
|
Author: xushiweixushiwei Date: Apr 28, 2008 21:30
>
> Great! IMVHO, it will only make your hard work much more flexible indeed.
|
| |
| no comments |
|
|
|
|
|
|
