Re: Complexity of protected objects

[Jim Rogers <jimmaureenrogers@worldnet.att.net>]

Dale Stanbrough wrote:

> Jim Rogers wrote:
> 
> 
>>Using a protected object to read and write files is a clear
>>violation of the intention and recommendations for proctected
>>objects. Protected objects should be non-blocking. I/O is
>>always potentially blocking.
>>
> 
> Why is this? I see this as being a piece of programming advice,
> - it's not a good idea to hold locks for a long time - but is 
> there any more to it than that? Are there some other consequences
> of scheduling than that?


It is good to understand why "it's not a good idea to hold locks
for a long time". The first reason that comes to my mind is the
need to avoid live locks and dead locks in your system.

Note that this is an entirely different issue from queueing up
protected entry calls because the entry guard is closed. Protected
entries are used to communicate state as well as data between tasks.

Blocking actions belong in separate tasks. Unless you are using
FSU threads this should allow other tasks to procede while one
task is blocked. Blocking during communication between tasks
often has a cascading effect throughout a system.

Jim Rogers