On Tue, 14 Oct 2008, Massimo Belgrano wrote:
Hi Massimo,
> Compliment you have made point six of your todo
> > 6, HB_LIBLOAD()/__HRBLOAD() may not be MT safe in some cases.
> > Before they will not be resolved please try to not use this
> > functions when other threads are executed.
Not fully:
> There is still one problem in MT mode which has to be resolved yet.
> When dynamic library containing PCODE using static variables
> is loaded 1-st time then it will force resizing of internal array
> with static variables. If in exactly the same moment some other
> thread operates on static variable then it may cause corruption.
> To resolve this problem we will have to divide continuous memory
> block common for all modules where we store all static variables
> into separated blocks bound with each PCODE module (symbol table).
This also have to be done and it's the most important part.
Rest was trivial and even before my modifications user could
use own MUTEX to serialize access to this functions.
Anyhow in last weeks I cleaned all other critical points from my MT
TODO/TOFIX lists. Here are current lists:
TOFIX:
1. Tracelog is not MT safe - not used in standard builds so it's
not a problem for normal users.
2. DEBUGGER is not MT safe. Now do not use debugger in code with
more then one thread active or it will crash.
Before we will touch this code please think how MT debugger should
work.
3. PROFILLER is not MT safe. It's optional code disabled by default.
Before we will touch it please think how it should work for MT
programs.
4. Divide static array into symbol tables
When dynamic library containing PCODE using static variables
is loaded 1-st time then it will force resizing of internal array
with static variables. If in exactly the same moment some other
thread operates on static variable then it may cause corruption.
To resolve this problem we will have to divide continuous memory
block common for all modules where we store all static variables
into separated blocks bound with each PCODE module (symbol table).
5. hb_threadQuitRequest() can be ignored by thread in some cases
due to race condition. It may happen if thread will overwrite
request send by caller simultaneously, f.e. by BREAK.
I can resolve it but we can also leave it as is and document
such behavior as expected or even remove this function. Killing
other threads in such way is dangerous and can be used only
for some simple situation. It's much safer when user uses his
own mechanism to terminate treads in some safe for his code places.
TODO:
1. We should check contrib code and eliminate non MT safe code
or document non MT safe functions.
2. Possible TODO: make RDD settings (rddInfo()) thread local.
Should we make it?
3. Thread priorities - is it really necessary?
best regards
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
