On Fri, 31 Oct 2008, Mindaugas Kavaliauskas wrote: Hi Mindaugas,
> one more proposition: SYNC[HRONIZED] I though about it at the beginning but there is one problem. We already have SYNC METHODS for xbase++ compatibility. This mechanism has one side effect which is xbase++ compatible: before thread enter WAIT state on SIGNAL object it unlocks synced messages. When is woken up then it lock them again. I do not like it because such mechanism can be source of deadlocks and it's not clear for me why xbase++ has it. Probably it's a workaround for race condition between unlocking some mutex and entering conditional variable. Windows does not have real conditional variables like in POSIX and such situation has to be resolved in different way, usually using semaphores. Anyhow race condition cannot be fully eliminated though can be reduced to level which is not danger for application synchronization. We also have such code in Harbour just like any other application written for MS-Win and using conditional variables. But because we have fully controlled MUTEXes which can be also CONDITIONAL VARIABLEs, MULTISTATE SEMAPHOREs and MESSAGE QUEUEs then we do not have to introduce such tricks which seems to be must in xbase++ to resolve some possible problems. I want to keep this new synced functions semantic simple and clean so they will not work like xbase++ SYNC METHODs which we are emulating. This causes potential problem for users when the same prefix will be used for different synchronization methods. This is the only problem and in my opinion it's quite good name. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
