Przemyslaw, Przemyslaw Czerpak wrote: > On Tue, 17 Feb 2009, Przemyslaw Czerpak wrote: > > Hi Maurilio, > >> The only one solution I see here is introducing >> second event semaphore and maybe also event queue if it will not be >> enough. I have to rethink it yet and build a model to not miss sth >> important. > 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-------------- > I think that the easiest way will be implementing real conditional > variables like in PTHREADS. > I will need for this event semaphore allocated for each thread and > keep waiting thread list for each conditional variable. To avoid > memory allocation at run time the waiting thread list items will be > part of HB_THREADSTATE. One thread can wait only on one semaphore > so we need only single item per thread. Because each thread will > use its own event semaphore then we can rest them and signal for > each thread without the bad side effects I was describing. > 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------------- > can try to use thread suspend/resume mechanism but in such case > 1-st I will have to carefully read OS2 documentation to not find > some new unexpected problems. > Below I'm attaching basic version of code which introduce conditional > variables working like in PTHREADS. Please look at it and tell me > what do you think about it. > If in OS2 thread can suspend itself for given time period and be > resumed on other thread request then we can eliminate even semaphores. > 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------------- I'll look at the code later. Thanks. Maurilio. -- __________ | | | |__| Maurilio Longo |_|_|_|____| farmaconsult s.r.l. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
