Re: Witango-Talk: threading model v4 vs. v5?

[Phil Wade]

Title: Re: Witango-Talk:  threading model v4 vs. v5?

The same type of scenarios were still possible in T2K, the threading model simply lowered the potential for them happening, but the side effect was that a taf that would take a long time to execute would slow the entire server down and you would have to wait for it to finish before you could execute even a small taf.  The new theading model allows for a large and small taf to run simultaneously and the small taf to finish without having to wait for the large taf to finish.

This issue means that you do have to plan how your applications runs and be mindful that it is a multi user environment and what the consequences of what a multi user environment could be doing with variables shared across multiple tafs and users.

By design T2K did things the same way - variable modifications were
made atomically, but at the action level (or between meta tags, depending on
what meta tags were used) the code that I quoted in the previous email would
still break the logic in an application that was coded that way on a T2K server.

You do not need to worry about a variable being written to simultaneously, the server handles the blocking of threads while doing this for you.

It is the code that references the same shared variable while the type of the variable is changed or is initialised with new values constantly by different tafs in different threads.  You can end up with tafs competing for the same variable and an unpredictable values stored in the variable or as a worst case scenario a variable type changed.

Take for instance the following executing this pseudo code:


<@ASSIGN mysharedscope$Var_A "I|am|a|string">
....
A few more actions later in the same taf
....
<@ASSIGN mysharedscope$Var_A "<@TOKENIZE request$Var_A chars='|'>">
....
A few more actions later in the same taf
....
@@mysharedscope$Var_A[1,4]


it is expected at this point that Var_A is an array and that the result of this expression/meta tag evaluation is expected to be a string,

but ...

If the above pseudo code was run by two request simultaneously, there is the chance that the tafs could produce an error when one taf has changed the variable @@mysharedscope$Var_A type to a string and the other taf thinks it is an array.  This is because the tafs are running in different threads simultaneously and switching processing time between them.

The the problem is in Var_A changing types.


You would not get this problem if the sudo code was like this:


<@ASSIGN request$AString "I|am|a|string">
....
A few more actions later in the same taf
....
<@ASSIGN mysharedscope$AnArray "<@TOKENIZE request$AString chars='|'>">
<@PURGE purge$Astring>
....
A few more actions later in the same taf
....
@@mysharedscope$AnArray[1,4]


In this case the variable types are static and there will not be any type mismatches.  I would also recommend to users to do all conversions in the request/local scope as it will be *so* much faster and is not shared. Once the proper variable is formed, it can be assigned to a shared scope variable safely.  Depending on the functionality of your application, you may still have problems, though, even with the code restructured as shown above, if two or more requests evaluate or assign the same variables using different strings, you may not get the results you thought you were getting.

Eg
TAF 1:  <@ASSIGN request$AString "I|am|a|string">
TAF 1:  ....
TAF 1:  <@ASSIGN mysharedscope$AnArray "<@TOKENIZE request$AString  chars='|'>">
TAF 2:  <@ASSIGN request$AString "I|am|not|the|same|string">
TAF 2:  ....
TAF 1:   <@PURGE purge$Astring>
TAF 2:  <@ASSIGN mysharedscope$AnArray "<@TOKENIZE request$AString  chars='|'>">
TAF 1:  ....
TAF 1:  @@mysharedscope$AnArray[1,4]
TAF 2:  <@PURGE purge$Astring>
TAF 2:  ....
TAF 2:  @@mysharedscope$AnArray[1,4]

Here, taf one gets the results from the tokenised taf 2 string.

The other situation where you may run into this type of scenario is if you initialise/define/purge a variable several actions before you actually assign data to it.   If you have two requests to the same variable, one initialising it and the other requesting it, there is a possibility that it will be in an empty state when requested.  The trick here is to ensure that the purge and the assignment to a new value are one after the other.

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