On Wed, 18 Feb 2009, Maurilio Longo wrote: Hi Maurilio,
> First, note that you have an api DosCreateMuxWaitSem() to wait for up to 64 > envent semaphores _OR_ mutexes (they cannot be mixed) with a single call, I > don't know if this can make your job easier, though. > --------8<-------------- > Semaphores are defined by OS/2 and reside in an internal memory buffer. They > are divided into three types, according to the functionality they provide: > > Event semaphores enable a thread to notify waiting threads that an event has > occurred. The waiting threads then resume execution, performing operations > that are dependent on the completion of the signaled event. > > Mutual exclusion (mutex) semaphores enable threads to serialize their access > to shared resources. That is, ownership of a mutex semaphore is used by > cooperating threads as a prerequisite for performing operations on a resource. > (Threads cooperate by using the mutex semaphore functions to ensure that > access to the resource is mutually exclusive.) > > Multiple wait (muxwait) semaphores enable threads to wait either for multiple > events to occur, or for multiple resources to become available. Alternatively, > a flag can be set so that a thread waits for any one of multiple events to > occur, or for any one of multiple resources to become available. > -------->8-------------- Thanks for the info. I was looking at DosCreateMuxWaitSem() but I cannot find in the documentation any information that I can pass to this function locked mutex and event semaphore and it will unlock the mutex waiting for an event or can reset posted event and such functionality is necessary to avoid race condition so I'm afraid it will not help us in this case. > > I only do not know how many event semaphores can be allocated per > > process. The maximal value may reduce number of threads which can > > be executed simultaneously. I hope it's bigger. If not then we > --------8<------------- > There is a system-wide limit of 65536 (64K) shared semaphores (including > mutex, event, and muxwait semaphores); in addition, each process can have up > to 65536 (64K) private semaphores. > -------->8------------- It's quite big. I do not think that it's possible to create more threads executed simultaneously in OS2. > There is a couple of APIs for this but they have this limitation which I think > makes them not suited for this task: > --------------8<------------- > A thread's execution is suspended when another thread in its process issues > DosSuspendThread, specifying the ID of the target thread. The thread may not > be suspended immediately because it may have locked some system resources that > have to be freed first. However, the thread is not allowed to execute further > application program instructions until a corresponding DosResumeThread is > issued. > > DosSuspendThread permits the suspension of only one other thread within the > current process. If a thread needs to disable all thread switching within its > process so that the calling thread can execute time-critical code, it issues > DosEnterCritSec and DosExitCritSec. > > DosKillThread will not terminate a thread that is suspended. Instead the > suspended thread will be terminated when it resumes execution. For this > reason, you should not kill the main thread of an application if there are any > secondary threads that are suspended. > > Note: This function is very powerful and must be used with extreme caution. It > should be used only when the state of the target thread is known. > -------------->8------------- And I do not see any simple mechanism to wake up suspended thread automatically and I do not want to create inspector thread. > I'll look at the code later. Thank you. I'll try to make necessary modifications in hbthread.c code but I will have to ask you to make compilation tests. I still haven't setup environment for cross OpenWatcom OS2 builds so I cannot even make simple compilation tests. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
