Before this thread explodes into a "Oh no what have they done to Witango 5
Server":
The exact same code pseudo code that Robert used would not work on T2K
either. On T2K if two tafs checked the same shared counter and incremented
it, T2K would keep on looping as well. If you have every wondered why
sometimes T2K never gave back results or timed out or taf than normally
worked, this may have been the problem.
It may or may not have happened often but T2K exhibits the same behaviour.
For example, this pseudo code may work 99 times out of 100 but will not work
as expected 100% of the time when run concurrently with multiple taf
requests as in a frameset, or from multiple browser windows on the same
machine.
if( user$count != 99)
user$count = user$count + 1;
else
user$count = 0;
It was a little-known fact that if two threads check the value of count in a
shared scope and find it to be 98, they will both increment the count,
resulting in a virtually endless loop (it will take a long time until count
overflows and the taf normally timed out). The fact that the server was
running in the cooperative mode didn't make this any safer - it would still
happen in a tight loop.
Faster CPUs, the better threading of the v5 server and higher concurrency
levels will expose these issues in shared scopes.
Regards
Phil
On 12/11/02 1:34 PM, "Robert Shubert" <[EMAIL PROTECTED]> wrote:
> Bill Conlon 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.
>>
>
> Bill, you are correct. There was some discussion about this on the beta
> list a while back as well. Basically, the example:
>
> thread A---
>
> WHILE @@domain$var != 100
>
> @CALC @@domain$var = @@domain$var + 1
>
> /WHILE
>
> and
>
> thread B---
>
> @CALC @@domain$var = @@domain$var + 1
>
> running concurrently, could result in thread A's WHILE testing against
> 99 then 101, essentially "skipping" 100.
>
> Witango has no inherent "TRANSACTION" statement that you could put
> around variables, so you would need to write protection code yourself
> for cases where multiple threads can cause corruption.
>
> Everyone should be aware of what this can mean in their applications.
>
> Robert Shubert
> Tronics
> ________________________________________________________________________
> TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
> with unsubscribe witango-talk in the message body
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
with unsubscribe witango-talk in the message body
