From: Anthony Williams (anthony_at_[hidden])
Date: 2007-01-30 06:02:01
"Kai Brüning" <kai_at_[hidden]> writes:
> I thought a little more about this topic. I am rather new to concurrent
> programming, and the most important lesson so far was that you typically
> overlook something, so it is quite likely that I do overlook something here,
> too, but anyway:
> Looks to me that indeed heap-allocating the function object might be the
> better solution. That is, thread::thread would create a copy of the function
> object on the heap and pass the pointer as parameter to
> thread_proxy. thread_proxy would than execute the function object and delete
> the pointer after returning. This would remove the whole condition variable
> and mutex overhead at the cost of a single heap allocation. I have no idea
> of the inner workings of a pthread condition variable, but since it needs to
> keep a list of waiting threads, it is not unlikely that at least one heap
> allocation happens anyway.
> The function object is copied once in both cases, currently in thread_proxy
> from thread_param to the thread stack, this would move to copy-construction
> into the heap block in thread::thread.
As you say, it's a trade-off --- heap allocation vs mutex/cond var. I can't
think of a particular reason why your scheme wouldn't work, but I guess Bill
didn't want to require a heap allocation for some reason.
-- Anthony Williams Just Software Solutions Ltd - http://www.justsoftwaresolutions.co.uk Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL