Hi, I am sending data to peers and those data need to be retreived from a scenegraph with a mutex to lock the data.

The process of gathering the data is taking a bit less than a ms. I'm starting the thread every time I want to gather the data. If I'm running at 60 fps, I'm starting the thread 60 times per second so is that a performance or design problem?

Would it be much better to have the thread always running and some kind of mechanism to ask him to perform the task whenever it's needed, so around 60 or 120fps?

Also, does starting a thread creates some memory alloc/dealloc and then produce on the long run some kind of fragmentation?

Thank you all.

Creating a thread is rather expensive operation.  You would have to look at the disassembly but I'm fairly sure there are allocations involved on the OS side of things.  Maybe look into a job system where you dispatch off small jobs to a thread pool.  Here is a GDC video and overview of how they multithreaded the Destiny engine:

Memory fragmentation is not really an issue, but creating and destroying threads that often might be a performance problem.  I'd recommend having a thread or pool of threads to which you give work as needed.  You'll need some synchronization mechanism so that the threads wait for work and then signal your main thread when they're finished.

I would create the thread once and make a semaphore which the thread waits on. Then I would signal this semaphore each time I wanted the thread to wake up and process new work for it. Once the thread has completed the work it would then wait (sleep) for the next signal. 

One thread per core is optimal, go beyond that and you start wasting CPU by switching between threads that have to wait for each other to run.

Thank you all for your advices, I'll change my design then. I'll look at a single thread with semaphore, I think this is the way to go. Again, thank you all to help me make a decision.