|
Templates, Tools and Utilities
for Clarion Developers
|
 |
 |
|
Add a comment to an Icetips Article
Please add your comments to this article.
Please note that you must provide both a name and a valid email address in order
for us to publish your comment. Comments are moderated and are not visible until they have been approved. Spam is never approved!
Back to article list
Search Articles
Add Comment
Printer friendly
Direct link
Clarion 6: Threading - 3
2002-12-15 -- Andy Ireland
Newsgroups: softvelocity.products.c55ee
> Just for clarification, but this is how I understand things (jump in
> anywhere to correct ).
>
> If I were to add some threading logic to my code, I would want to use the
> Mutex interface (assuming SV is providing one).
No, You would use a critical section which is a mutex except in the sense
that under windows OS's a mutex can cross process boundaries wheras a
critical section cannot.
> The reason being is that if
> I ever get into a deadlock condition, the OS will kill a Mutex if not
> released.
Ok, don't follow your logic here, if you get into deadlock, you get into
deadlock, end of app (simple as that) CTRL ALT DELETE. What I was saying is
that there are scenarios that threading novices will eventually hit if they
are coding blindly as they have always done in the past due to an over
simplification of the magnitude of the changes in C6. An example was that
under certain circumstances, the app will be locked within the supplied
process mutex, or similar condition and as such people should be thinking
about the way they design thier apps differently, not just in how they
necessarily treat thier data. Another example was that of entering a
critical section that has already been entered (most people will do this at
some point and they will not have a clue what is causing the problem) etc.
My point is that this whole subject has to date been vastly over simplified
as are most things on the NG's. It is not helpfull that the suggested
changes people make to thier apps revolve solely around critical sections as
has been stated. This is absurd. There are lots of different synchronisation
primitives not just critical sections which exist to solve different
problems. Take suspend / resume. My understanding is that these wrap one of
the wait conditions. How many people here understand the wait functions in
the API? How many people will fall over themselves with these functions? If
people are still asking the level of questions they are, then I'd say most
and it's not SV's job to teach people how to code. People know what's
coming, they should be reading up on things like...
creating and use of critical sections / mutexs / semaphores / spinlocks
Wait functions like WaitForSingleObject / MultipleObject etc
Event functions such as CreateEvent / SetEvent
and the list goes on. Now most people can get away with never needing to use
any of those functions bar critical sections however if people try to
accomplish what they have been able to using clarion because it's been
mutexed all this time, then they absolutely will need to use them if they
don't want to do wholesale redesign of portions of thier apps. Timing of
when things occur is now just as important. The grunt coding is still taken
care of for them to a certain extent but the pitfalls are not.
> Otherwise, if I know exactly what I am doing on a process, I
> would want to use a critical section because they are faster.
Nope, critical sections will slow your code as they cause blocking on shared
code therefore you should keep them as small and tight as possible. The
fastest code is unblocked code. A redesign is almost always preferable.
Regards
Andy
Plugware Solutions.com Ltd, taking the puzzle out of I.T
Tel : +44 1249 813335
Fax : +44 1249 813462
Today is November 21, 2024, 7:28 am
This article has been viewed 35307 times.
Google search
has resulted in 20 hits on this article since January 25, 2004.
Back to article list
Search Articles
Add Comment
Printer friendly
|
|
|
