Unique buffer per thread

[Alphadan]

hi

I have a program that runs on a multithreaded enviroment but it needs to store things on a buffer the trouble is that i need a unique buffer per thread else the data would end mixing up.

actually i do use a char array allocated on one intialization function on the class (cant be called on the constructor) since only certain instances will need it. and else i would get ou of memory.

my buffer is a char array allocated in the heap, my main problem is that i cannot have a unique pointer to each of these buffers.

if i declare the pointer as private member of the class i would have only one pointer in all threads right?

how would i acomplish this goal, sugerencies and recomendations are welcome.

thx in advance!!

[Marc G]

I don't quite understand your design.
Apparently you have a class with your buffer in it.
Can't you instantiate 1 instance of that class for every thread?
That way, each thread has its own buffer.

[Alphadan]

I don't quite understand your design.
Apparently you have a class with your buffer in it.
Can't you instantiate 1 instance of that class for every thread?
That way, each thread has its own buffer.

thx for your answer, it was a confusion i had and misunderstanding about classes. I declared my pointer to the heap allocated buffer as a private member variable on my class and each instance now works with its own buffer.

Thx anyways =)

[Lindley]

Most threading libraries have support for thread-specific data. In particular, I've used the Boost.Thread library's thread_specific_ptr smart pointer class to safely store buffers in a one-per-thread manner; this is more efficient than creating a separate buffer for each object or, worse, one for each time an object does a certain computation.

[OReubens]

TLS is a means to an end. It allows DLL's to allocate storage on a per thread basis without formal support from the thread itself.
Or it allows a per-tread equivalent of a 'static' variable without formal support from the thread itself.

The efficient way however is to have the thread manage storage on it's own stack.
This can be regular local scope variables, a local scope pointer to allocated storage (allocated either in the thread, or prior to callign the tread and passed as data).


Due to compiler support TLS can LOOK to be efficient, but there's usually quite a bit of code support hidden behind it.
Of course it depends what you meant by efficient. Efficient in the sense of "fastest running code" or "smallest possible code" then the answer is no.
If you meant "efficient for the programmer since you have to prepare/plan less", then the answer is maybe...

[Lindley]

I'd think that allocating a TLS once per thread in a thread-pool design would be more efficient than creating a vector on the stack which is constantly going to be going in and out of scope. Am I wrong for some reason?

[Alphadan]

thx for the sugerencies.

btw i would rather to use the stack since is the safest way to stay in a thread safety state, but in this case i cant use stack cause the function needs to support re entrances so if i allocate the buffer on the stack on the next call it would get automatically destroyed.

so i allocated on the heap but not in the constructor but instead on another methood which is called when the buffer will be necesary.

and i carefully destroy the allocation when no longer needed.

btw that about the smart pointers is really interesting i read an article about them but im not sure they would help me in this case since if both threads will write/read to the buffer i would need 2 copies for the buffer or data will get mixed up.

[OReubens]

who's talking about a vector ?

I'm talking about

DWORD ThreadProc(LPARAM lParam)
{
    DWORD dwMyLocalVar;
    ...
    dwMyLocalVar = 14;
    ...
}

vs

DWORD __declspec(thread) dwMyThreadVar;
DWORD ThreadProc(LPARAM lParam)
{
    ...
    dwMyThreadVar = 14;
    ...
}

The stack variable requires less support code to get it working/allocated, and it is just a local scope variable in accessing.
The TLS approach in C++ code seems equally simple, but it hides quite a bit of support code the compiler is taking care of.

For all intents and purposes, the 1st approach is prefered where feasible.

If you're making something functionally equivalent to say, a per-thread singleton, then requiring the thread to know about this and pass this down to the class isn't going to work well. TLS serving the purpose of the per-thread-equivalent of a member static makes it an easier/better design, even though it adds (hidden) overhead.
Although I HAVE seen/used libraries that required you to call an initialisation function per thread passing in a unique pointer to a structure where the library would store per thread data. It's equally easy to use, but it does require a more formal setup. TLS means you can make a library that supports multithreading and you don't have to worry users about maintaining datastructures on your behalf.

I usually make a class for my thread procedure. the class has a static member function serving as the thread entrypoint, this function does nothing other than creating a local stack instance of the class and then calls the 'run' function of the class.

After this, most of the "passing the data around" happens automatically because it's all (nonstatic) member functions of the class.

[Lindley]

btw that about the smart pointers is really interesting i read an article about them but im not sure they would help me in this case since if both threads will write/read to the buffer i would need 2 copies for the buffer or data will get mixed up.

Well, that's exactly what thread_specific_ptr is supposed to handle for you.

[MilesAhead]

I don't quite understand your design.
Apparently you have a class with your buffer in it.
Can't you instantiate 1 instance of that class for every thread?
That way, each thread has its own buffer.

How about something like this?

template<class T>struct Buff {
	size_t size;
	T* t;

	Buff() : size(0),t(0) {}

	Buff(size_t n) : size(0),t(0)
	{
		t = new T[n];
		if(t)
			size = n;
	}

	bool operator!()
	{
		return !t;
	}

	T& operator[](size_t i)
	{
		if(i >= 0 && i < size)
			return t[i];
		throw "index out of range";
	}

	const T& operator[](size_t i) const
	{
		if(i >= 0 && i < size)
			return t[i];
		throw "index out of range";
	}
		
	~Buff()
	{
		size = 0;
		if(t)
			delete [] t;
		t = 0;
	}
};

To get a char buffer declare a variable in your thread like:

#define BUFSIZE 4096
Buff<char> buffer(BUFSIZE);

You can spiff it up with iterators or dereferencing '*' operator or whatnot.
When it goes out of scope, the memory is freed.

[Marc G]

Why reinvent the wheel?
Just use std::vector or the C++0x std::array for fixed arrays.