Right. If the shared access is read only, no problem. But if multiple
threads can write to a shared variable, then we need to have some kind of
transaction/blocking technique. I'll repeat the one I proposed:
if (scope$active>0) //check the semphore scope$active
Another thread is using the variable(s) associated with the
semaphore.
Cannot continue this thread!
else
scope$active=scope$active+1 //mark the semaphore as being used by me
endif
if (scope$active=1) //double check semaphore
The variable is available, so process variable(s) associated with
the semaphore
else
Oops! Another thread got to the semaphore between the previous
endif and this one.
Must handle this error condition. Maybe just decrement the
semaphore and exit this
thread.
endif
scope$active=scope$active-1 //release the semaphore
return
Now the question is what to do when the semaphore is blocking a taf. In
the case of user scope, you can probably just present "Sorry, the server
was busy. Please try again."
For application or system scope, a case-specific analysis is needed.
What I would like to see is a threading model that supported a MetaTag
that allowed me to release the thread from its current active execution
state, to just put it back in the pending pool. That way, I would know
that my taf would eventually execute.
>
>So the issue is not so much having to put in critical sections around code
>which can be exceptionally difficult to troubleshoot a deadlock, but coding
>so that these types of scenarios do not occur or when they do, you have an
>understanding of where, when, how and what variables can be modified. If
>you have this understanding, you can add code that will handle these
>situations.
>
>A few generalised rules:
>
>1 Where possible use request/local scoped variable. They are also faster.
>2 Avoid counters and counter tests in shared scopes they are dangerous and
>tricky to trouble shoot
>3 If you cannot avoid shared counters, code in a blocking mechanism to
>stop another tafs accessing the section of code with the shared variable.
>Eg <@IF "!@@sharedscope$CodeSectionBlocked">Set Blocking Mechanism;Run
>Code;Reset blocking mechanism</@IF>.
>
>Apologies for the essay.
>
>Regards
>
>Phil
>
>
>
>On 12/11/02 11:39 AM, "Bill Conlon" <[EMAIL PROTECTED]> wrote:
>
>> This brings up the question of thread-safe coding, as was discussed in
>> the thread "a random question" by Alan Wolfe on 9/24/02.
>>
>> It seems to me that this threading model now imposes new requirements on
>> applications programmers to assure that their shared variables are
>> properly protected. It seems to me that writeable variables in the
>> application and server scopes now need to be wrapped with protection
>> since they can be changed by other threads.
>
>------ End of Forwarded Message
>
>
Bill Conlon
To the Point
345 California Avenue Suite 2
Palo Alto, CA 94306
office: 650.327.2175
fax: 650.329.8335
mobile: 650.906.9929
e-mail: mailto:bill@;tothept.com
web: http://www.tothept.com
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
