Imagine your thread has locked a major resource, now you suspend that thread. A instant deadlock occurs because that thread will never release that resource.

Of course it will.? It's called a bug.? If I write moronic code, it will cause problems, whether it's single or multi threaded.? Using this as a justification for the use or non-use of threads is like saying you can't use divide because some muppet might try and divide by zero and crash the code!

I look forward to the day when my OS starts scheduling my application using OnIdle events.

nice! sometimes the solution is simpler than you think :)

patient - if i do this it hurts,
doctor - don't do it then

you could consider
- check for locked resources after suspending the thread, resuming locking thread of necessary
- a 'server' thread that other threads send messages to, a bit like a database server but for your imaginary app.
- theres probably plenty of ideas to resolve/work around this if you search web

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100921/a6b11bc4/attachment.html>

Hello Lazarus-List,

Wednesday, September 22, 2010, 12:12:31 AM, you wrote:

V> nice! sometimes the solution is simpler than you think :)

V> patient - if i do this it hurts,
V> doctor - don't do it then

V> you could consider
V> - check for locked resources after suspending the thread, resuming locking V> thread of necessary
V> - a 'server' thread that other threads send messages to, a bit like a V> database server but for your imaginary app.
V> - theres probably plenty of ideas to resolve/work around this if you search V> web

Direct use of suspend/resume in i386 at least is a call for serious and very, very difficult to track problems. A simple code like:

if A=0 then Thread.Suspend;
DoSomething();
if Thread.Suspended then Thread.Resume;

Is not garanteed to end in a thread with a resume state. I had experienced (unfortunatly) this problems in the past, and finally changed to events, but it can also be changed to other functions to not call suspend/resume directly and ensure the thread transition from state to state is completed.

One other thing to think about is something I do often which is to have a "suspend needed" boolean variable for threads. So if a suspend is needed it will be processed at an appropriate section of code where the thread itself knows whether or not it is indeed safe. Other wise it will remain pending for that thread until such time as it can reach a suspended state, trip another flag, and suspend.

So these issues are not trivial but are somewhat easy to ensure safety during suspend/resume calls. Just requires a bit of advanced skills when dealing with threads to remove risks associated with causing race conditions.

Jos? Mejuto wrote

Direct use of suspend/resume in i386 at least is a call for serious and very, very difficult to track problems. A simple code like:

Hello Andrew,

Wednesday, September 22, 2010, 4:50:38 PM, you wrote:

AB> One other thing to think about is something I do often which is to AB> have a "suspend needed" boolean variable for threads. So if a suspend AB> is needed it will be processed at an appropriate section of code where AB> the thread itself knows whether or not it is indeed safe. Other wise AB> it will remain pending for that thread until such time as it can reach AB> a suspended state, trip another flag, and suspend.

I'm not sure now that my memory is not corrupt :) but I think that a code like:

Thread.Suspend;
Thread.Resume;

Called from different threads could put the thread in a dumb state where it is suspended but it can not be resumed due something like a resume arriving after the suspend has been started, but not finished, so I think it is only "safe" using critical sections.