Hi,
I'm currently not able to look into this, but I'm afraid that you're both right and wrong. Worker Threads/Queues are nothing more then an executive version of the kernel KQUEUE. I don't know why are using special structures and code...all that ExQueueWorkItem should do is call KeInsertQueue with the right parameters/queue name...I don't understand the point of using Events and Semaphores... KeRemoveQueue implements all the waiting necessary...a worker thread, in the entrypoint, simply loops by calling that function, which does the actual waiting (Even on ROS we have this!). You're both right that EVENTs and SEMAPHOREs are wrong...
I see it as utterly pointless to be working on a parallel implementation which seems to be broken no matter how you do it...just use KQUEUES like it should be done, and I believe this will be solved.
Best regards, Alex Ionescu
Gunnar Dalsnes wrote:
you have changed the semaphore to a synchronisation event. If all worker
threads have a job and there are
put more than one new job in the queue, only one of the jobs is delivered
to the workers. The first empty
worker removes one job. The event is never signaled again. All other jobs
are never delivered to the
workers.
I don't understand how you are thinking.
SyncronizationEvent = AutoResetEvent. It shouldn't be possible for a work item not to be delivered. If any worker threads are allready running, the ExInterlockedRemoveHeadList loop will execute the work item. If any thread is waiting on the event, it will be woken. We/I could examine a more detailed scenario if you want.
Compiling ros on ros isn't the real problem. I use three pc for testing.
On two pc I can compile
ros on ros without any problems. The third pc is a smp machine. On my
third pc, the problem is somewhere in
the smp code (and in many of my not commited changes).
The new tcpip.sys generates lots of work items, and while compiling ros-on-ros it bsod'd for me with STATUS_SEMAPHORE_LIMIT_EXCEEDED exception. If you look at the old code, this can easily happend if the worker threads are busy looping and dequeing items, without ever entering the wait.
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev