Thread synchronization

Hi, all,
problem: I'm going to write service app, which will monitor set of directories. This service app will be controlled from external application using windows messages (e.g. for changing directory to monitor). It seems to be necessary to use 2 threads - one for service itself [Main] and another for real processing [Process], because it will need to do kind of full scan of directory, and that might be time-consuming, especially over the network. The idea is to have TList [FIFO IIRC]: Main will add user requests to the end of the list and Process will take items out of the list one by one starting from first one and execute them.
How to synchronize usage of TList? Seems that list should be locked when item is being added [Main] and removed [Process]. What's the best way to do that? Process thread will lock list, get item, update list, unlock it and then process the action, so list (hopefully) will not be locked for a long time. How to handle a situation when the list is locked by Process and WM arrives to Main?
Also what is the best way to check the list for new items in Process Thread?
Code samples would be fine.

W_Fox
W_FoxAsked:
Who is Participating?
 
Lee_NoverConnect With a Mentor Commented:
you should use the TThreadList like:

with ThreadList.LockList do
try
  // do your stuff with the items
finally
   ThreadList.UnlockList;
end;

and a really good site about threads :
http://www.pergolesi.demon.co.uk/prog/threads/ToC.html

I've also done this queue thing you're planning
maybe you should check out TCommThread and the QueueCommand procedure
http://lee.nover.has.his.evilside.org/isapi/pas2html.dll/pas2html?File=/delphi/MiscFiles/vn_common/lnVidTypes.pas
0
 
TOndrejCommented:
Have a look at TThreadList which implements a thread-safe list. (See LockList/UnlockList methods.)
0
 
W_FoxAuthor Commented:
Sounds nice, TThreadList seems to be the way to go :)
Do I need to check whether the list is locked or not when calling MyList.LockList? This will happen if list is locked by any of threads and message or timeout occurs in other thread. List will be unlocked for sure when processing ends, but it is possible that MyList.LockList will be called twice or more w/o UnlockList.
0
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

 
CynnaCommented:
W_Fox,

If you have D5/6 (not sure for D4), the natural object for FIFO would be TQueue. Also, you could use TCriticalSection for locking (that's how Lock/Unlock are implemented in thread-safe components).


>Do I need to check whether the list is locked or not when calling MyList.LockList

No - that is the purpose of Lock/Unlock - to let OS do it
for you. As soon as you lock an object, everybody who hits
Lock of the same object will be immediately frozen, waiting
for Unlock. I'd advice you too read up on critical sections,
you won't get very far in multithreading without completely understanding those.

0
 
TOndrejCommented:
You should always use try..finally as Lee_Nover suggested to make sure that the lock is released when no longer needed.
When thread B calls LockList and the list is already locked by thread A, then thread B enters a waiting state (execution is blocked within LockList) until thread A leaves the critical section. Thread B then acquires the lock (enters the critical section) and only then execution returns from LockList and continue executing.
0
 
W_FoxAuthor Commented:
Lee Nover's comment will be accepted as answer, particularly because of the link :) TOndrej, 100 points to you as well for TThreadList and 50 points to Cynna for TQueue.

Thank you, guys, you really helped me.
W_Fox
p.s. If I'll run into problems with threads, I hope I can contact you for advice :)
0
All Courses

From novice to tech pro — start learning today.