[vdr] Re: thread safeness II

[Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de>]

clemens@1541.org(Clemens Kirchgatterer)  05.12.04 12:07

>Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de> wrote:

>>   static char *buffer = NULL;
>>   const char *p = s;

>[..]

>>   return s; <======== is derivated from buffer, which is
>>   "(re)malloced"
>>             ( that will work every elegantly in single threading,
>>               but in multithreading two tasks overwrites or
>>               invalidates the memory of the other.)
>> }
>>
>> why is buffer "static" when it contains an malloc pointer?
>> Is it it worth?

>static is needed in this case. 

Yes. as i said: That construct is absolutely OK and
very elegant for single threading.

>buffer would get lost between
>subsequent calls to strescape otherwise. 

That would give only a memory leak, but not segment faults
or "funny" effects.

Example:
Now it could happen that one thread "A" got "0x1200" as address of the buffer
and is working on/with 0x1200 keeping that value in a register.
While thread A is working, it loses the CPU to thread B.
The second thread B uses the same function call and does a realloc moving 
the entire new buffer to 0x4500 and realloc frees "0x1200" (nothing 
guaranties that the realloc will return the same pointer, 
but any way it would not matter at all as thread B would not be 
delighted that A manipulates/reads it's data).
What will happen if A tries to access 0x1200 which it has
stored in one of its registers when it's back to CPU?
Hopefully a segment fault...(but typically not ;-()
But what if third task C needs memory and get the 
"recycled" area at "0x1200" by his call to alloc(not this function!)?
There will be no problem as long as A is not using that memory ;-)
If A is access the memory, it will find the data of thread C
or worse will manipulate the data of C.
There is no obivious relation between C and the tasks A or B
not it is required that C uses this function.
That's the "Happy debugging lottery" of multithreading..

A fault may occure hours(!) later after the actual mal function
in a totally unrelated area.


>realloc on a NULL pointer is
>the same as malloc and would produce a memleak.

>> So why no mutex while using that buffer?

>is the function called from multiple threads? 

I don't know. 
Is it prohibited by anything?
Will you guarantee it that never ever some someone
uses that function (maybe implitcit)?
The problem is, that all will work well. Mostly...


>if yes there should be a mutex around it.

That would require that the mutex can be released
by the calling thread! (See the above example!)
Too that may lead to dead locks.
And nobody would expect such a function to block.

I would prefer that the calling thread frees the memory
when it does not need it anymore.

The "costly" malloc may be avoided by using a "queue" which 
contains preallocated memory blocks.
Instead of freeing the memory, the calling task simply 
returns the pointer back to the queue.
The disadadvantage: you must know how many memory blocks in 
what size you need.
The advantage: This works with a not-thread-safe-malloc too
and is really fast.
But is a malloc really so costly or the function called that often?


Rainer