[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaTask 1.6.1
- From: Daniel Quintela <dq@...>
- Date: Tue, 03 Jul 2007 14:31:32 -0300
Kacper Wysocki escribió:
A race with the aTask pointer update might be your problem :-/
If I understand the design of LuaTasks right, there may be several
threads calling into functions in ltask.c at once, and they are only
synchronized with the tlMutex global. You do well to serialize updates
to the aTask pointer, however there are several functions which do not
lock on access (reg_tasklist, reg_taskreceive, reg_getqhandle), which
lead to a race. Let me illustrate:
Let's say the realloc executes, and returns a new pointer ('te' in the
above code snipplet). realloc() needn't return a new pointer, but
often it will do just that. The old pointer - the global aTask, is
free() and invalid right after the realloc() call, yet any other
thread that has the old pointer might end up dereferencing aTask
before you manage to assign it the new pointer.
That should explain your random crashes, and why they don't always
Solution? Lock all accesses - reads and writes - through any globals
in a multithreaded environment.
Yes... the problem is aTask...
Inside "taskthread" there is a pointer to his own TASK_ENTRY
structure... well... after the realloc: it points to The Limbo.
I'm changing the allocation/reallocation scheme.