What would be the best programming practice for this case:
I have a linkedlist with file-objects, once in a while incoming file objects are added to this list (AddThread).
These file-objects need to be “processed”, supposedly by another thread (ProcessThread). So whenever file-objects are added to the list, they need to be processed one at a time, while other file-objects still can be added to the list.
During processing, an item from the list is read and afterwards removed from that list. Processing stops whenever the list is empty, and starts again if new items are added.
How I see it:
Whenever a change is applied to the list (item added), a change event is fired. This event wakes up the ProcessThread. The ProcessThreads locks the list for a small amount of time to read it and releases the lock again. When the file-object is processed it locks it again to quickly remove the item from the list and unlocks it.
When there are no file-objects anymore in the list, the ProcessThread is set to sleep.
Is this the right way to do it, or are there other better options..?
Greets Daan
Edit: I use a linkedlist, because then I can add a file-object on the beginning or the end of the list, so that it is processed before/after others. Processing can take up to a minute, depending on the networkload. Sometimes it will fail, and it needs to be processed again.
OK, after reading the other posts and updates, how about two ‘plain’ queues, (low and high priority), a mutex/CS lock and a semaphore, making up a priority blocking queue? To add a file-object, acquire the lock, push the file-object onto one of the queues, release the lock, signal the semaphore. In the process-thread/s, wait on the semaphore, acquire the lock, TryTake from the high-priority queue and, if this fails, Take from the low-priority queue, then release the lock and process the file-object.