ASP.NET AJAX Discussion and Suggestions

Re: Mutex + Javascript in AJAX rtm?

InfinitiesLoop — Mon, 12 Jan 2009 19:10:57 GMT

That site is wrong I'm afriad to say. There's only 1 thread in JavaScript. You can appear to duplicate the conditions of multiple threads if you involve modal dialogs, such as an alert(), but ajax apps wouldnt typically do that, and even if they do, there's a really simple workaround to ensure you dont get a race condition -- call the alert() on a setTimeout call, so you don't pause execution of the current call stack. A mutex simply is not necessary in JavaScript.

Re: Mutex + Javascript in AJAX rtm?

thedoug — Mon, 12 Jan 2009 13:27:57 GMT

Then, why this site says that there is race conditions with AJAX?

http://www.developer.com/lang/jscript/article.php/3592016

There are many others sites saying about mutexes in javascript.

I need this information. The AJAX callbacks are processed in paralell?

Thanks........

Re: Mutex + Javascript in AJAX rtm?

InfinitiesLoop — Wed, 26 Mar 2008 21:31:51 GMT

There is no race condition on 'cbCount'. Even if the two requests complete at the same time, only one callback is going to execute at a time -- each one in its entirety, because there's no concurrency or multi-threading in javascript. Rather, when the 2nd request completes, a 'task' is queued to execute its callback, which can't occur until there's no other javascript already running.

People I think believe there's concurrency because they'll insert an alert() into the callback to try to prove it. If you do that you will indeed see two different alerts come up at the same time. But that's not because they are executing at the same time, it's because alert() causes the browser to defer execution of the rest of the context and move on to something else. If you use any other means to try and prove concurrency, you will fail, because there isn't any. If you are going to have alerts() in your code then maybe you need to worry about this kind of thing.

Re: Mutex + Javascript in AJAX rtm?

indo_gangsta — Wed, 26 Mar 2008 21:17:21 GMT

LudovicoVan, Your above code has a race condition for the variable "cbCount".

Seriously, does anyone know of mutex implementation for ASP.NET Ajax? The above code is a good example of why we need one.

Re: Mutex + Javascript in AJAX rtm?

LudovicoVan — Fri, 24 Nov 2006 16:07:56 GMT

Hello back, here is maybe a more significant example.

Say we have to issue two server calls returning an integer, then get the sum of the two integers and use that in a third function. We are not guaranteed the order of execution for the two callbacks, neither we actually know when they are going to return a value at all. How we could "architect" this? Here is some code, not perfect because it still is a generic sample, so no point in "optimizing", yet should give some hints:

var cbCount, cbValue1, cbValue2;

// Whatever the timing, these two callbacks
// won't run concurrently, so no need
// for a synchronization mechanism
function httpCallback1(v) {
   cbValue1 = parseInt(v, 10);
   if(++cbCount == 2) finishProcess();
}
function httpCallback2(v) {
   cbValue2 = parseInt(v, 10);
   if(++cbCount == 2) finishProcess();
}

function startProcess() {
   cbCount = 0;
   startHttpReq1(httpCallback1);
   startHttpReq2(httpCallback2);
}

function finishProcess() {
   var sum = cbValue1 + cbValue2;
   alert(sum);
}

startProcess();

A bit improperly, anyway here we might think of the cbCount as a "semaphore".

Hope this can shed more light. (Does it?) -LV

Re: Mutex + Javascript in AJAX rtm?

LudovicoVan — Thu, 23 Nov 2006 03:39:13 GMT

aosipov:
What is my example then? Here's a definition out of Wikipedia "Concurrency occurs when two or more execution flows are able to run simultaneously." What am I missing?

JS is not concurrent, that is you never ever have two paths of execution running at the same time in the context of the same host (in our case, a browser's window). What you get is incorrect sequence of execution, not concurrent execution.

aosipov:
Like I said previous, this example was a demonstration of concurrency

Again, it is not concurrent. It just shows a messed-up flow.

aosipov:
I can repeat the same behavior with asynchronous callbacks, that is I can make a request that calls one of my callback functions in parallel to another function executing.

This should simply not be the case, so maybe post a sample...

In the meantime I'll tell you that this approach would mess the flow up:

   // Which runs first?
   StartHttpRequest(httpCallback);
   StartTimer(timerCallback, 2000);
   function httpCallback() { doSomethingFirst(); }
   function timerCallback() { doSomethingAfter(); }

This approach instead would work reliably:

StartHttpRequest(httpCallback);
function httpCallback() { doSomethingFirst(); doSomethingAfter(); }

There is no concurrency, it is a matter of "sequence". -LV

Re: Mutex + Javascript in AJAX rtm?

aosipov — Wed, 22 Nov 2006 21:42:05 GMT

I have seen this same problem w/o using alerts but with XTR callbacks.

Re: Mutex + Javascript in AJAX rtm?

InfinitiesLoop — Wed, 22 Nov 2006 21:35:39 GMT

I think it may appear that there is concurrency when in fact there isn't... when an Alert is open, the browser may divide the code into seperate tasks, and there are situations where other code may run while the original alert is open. But without the alert there could not be any concurrency. Basically using alert to try and prove concurrency isn't going to work. You can get multiple paths through the same code using this trick but only if you introduce an alert -- it cant happen otherwise.

Re: Mutex + Javascript in AJAX rtm?

aosipov — Wed, 22 Nov 2006 17:09:32 GMT

LudovicoVan:

Not only you can control the sequence of events, but - again - there simply is NO CONCURRENCY in JS.

What is my example then? Here's a definition out of Wikipedia "Concurrency occurs when two or more execution flows are able to run simultaneously." What am I missing?

LudovicoVan:

The basic problem (IMHO) is that you are mixing concepts from other languages completely different from the JS and its runtime model. That's why I am basically only stressing that you should know your language, rather than ask for foreign constructs you are more familiar with. Those constructs simply do not apply here!

To guarantee atomicity I use a mutex. This is a concept that applies to languages that are able to execute flows simultaneously. Javascript may not be such a language and I am not agruing that it is. The implemention of Javascript in IE and Opera (but NOT FIREFOX) allows for parallel execution and thus arises my need for concurrency control. The IE and Opera javascript runtime model (to use your words) allows for concurrency as demonstrated by my example (I am sure this was a design decision to allow faster rendering). In a perfect world, Javascript would be single threaded and would lock the window global object to updates until the current code is finished executing - this would guarantee a safe environment where no race conditions can occur. This is what Firefox does. To restate again, this is NOT the case in IE and Firefox. Therefore I need to guarantee some of my updates are atomic and therefore I use mutex implementation.

LudovicoVan:

The code above is simply wrong. It misbehaves because you have written it so that it cannot but misbehave...

Like I said previous, this example was a demonstration of concurrency showing the base problem (in the simplest way I could think of). I can repeat the same behavior with asynchronous callbacks, that is I can make a request that calls one of my callback functions in parallel to another function executing. The reason I made this example is because it is much easier to catch because there is no timing involved and I can control the timing myself and preproduce the problem every time, rarther than reproducing the problem under certain circumstances that are hard to simulate in an example (if not impossible w/o extensive retries).

I am not sure how I am incorrect here. LV, I too appreciate your effort to uncover the real needs here!!! I understand your point that javascript doesn't have concurrency but in the real world of browsers we must work around different implementations so I am looking for the best way to do this and possibly get this included in a standard framework (AJAX). This is pretty important.

Re: Mutex + Javascript in AJAX rtm?

LudovicoVan — Wed, 22 Nov 2006 16:26:59 GMT

aosipov:
I cannot control the sequence of events (at least in IE and Opera) and cannot guaruantee that a function will not run concurrently.

Not only you can control the sequence of events, but - again - there simply is NO CONCURRENCY in JS.

The basic problem (IMHO) is that you are mixing concepts from other languages completely different from the JS and its runtime model. That's why I am basically only stressing that you should know your language, rather than ask for foreign constructs you are more familiar with. Those constructs simply do not apply here!*

aosipov:
I could be wrong but I am pretty sure my example shows the fundamental problem (of course not in a real world scenario).

The code above is simply wrong. It misbehaves because you have written it so that it cannot but misbehave...

aosipov:
Am I on crazy pills?

Incorrect is not crazy, and I appreciate your efforts to get deeper.

So, now I'll stop and wait with you for more feedback, in case anybody has something to add.

-LV

*With an analogy: var x = "2" + "2" not giving back 4 doesn't imply - say - that JS lacks operator overloading, it would rather imply the programmer doesn't know what (s)he is doing...

Re: Mutex + Javascript in AJAX rtm?

aosipov — Wed, 22 Nov 2006 16:02:58 GMT

This was a proof of concept in the most simple example that I could make without adding complexity of a real world application. I have experienced similar problems (concurrency based) in real world applications but I cannot post this code nor would anyone examine it. To get back to the real problem, with asynchronous callbacks I cannot control the sequence of events (at least in IE and Opera) and cannot guaruantee that a function will not run concurrently. This is not a problem for me as my code is already ready for such guaranteeing critical sections and critical data are locked during execution. The point of this post was to get Atlas/AJAX team to recognize that a problem exists and possibly get a generic solution included in AJAX so we don't have to roll out our own custom solutions. This seems to be a general enough problem that a lot of programming languages or standard libraries include mechanisms to work around it and it seems reasonable for AJAX as a client side library to provide a similar mechanism. I could be wrong but I am pretty sure my example shows the fundamental problem (of course not in a real world scenario).

Am I on crazy pills? I would love not to have to resort to such complexity in javascript if someone can explain to me a viable alternative to guarantee my global memory will not be corrupted/modified concurrently. Please help!

Alex

Re: Mutex + Javascript in AJAX rtm?

LudovicoVan — Wed, 22 Nov 2006 14:12:19 GMT

aosipov:
Here's a simple example where I think a Mutex implementation may be necessary.

I'm afraid your sample is not very much significant. Apart from the fact that it is quite far from any real life code, the basic problem is that - as said before - in JS the "sequence" of the messages is what matters, and you have actually messed that up, so that it can't but misbehave... you wrote it to do it! (E.g. you call "before" what you are really executing "after", and you try to get results from the same opening method, while you should really do that from the popup *after* the popup has finished...)

aosipov:
By the way, the mutex implementation is only 30 lines (not 10,000 as you say).

10000 stands for far-too-many, and I was talking about the client-side frameworks in general there.

-LV

Re: Mutex + Javascript in AJAX rtm?

aosipov — Tue, 21 Nov 2006 17:29:24 GMT

Hi again LV - I am glad someone is interested in figuring this out with me.

Here's a simple example where I think a Mutex implementation may be necessary. Create the following page and then launch in IE (make sure to allow popups and not using tabs for new windows!).

<html>
<head><title>My test page</title></head>
<body>

<script type="text/javascript">
var o = window.opener;
function changeParentValueInParallel() {
  if (o && !o.closed) {
    o.changeValue('b');
    alert('Parent property changed');
  }
}

window.MyProperty = 'a';
if (!(o && !o.closed)) {
  window.changeValue = function(v) {
    window.MyProperty = v;
  }
  
  window.open(window.location);
  alert('Stage pre change parent window.MyProperty: ' +
        window.MyProperty +
        '\n\n' +
        'Before clicking OK press the Click me button in the child window');
  alert('Stage post change parent window.MyProperty: ' + window.MyProperty);
}

</script>

<input type="button" name="invoke" onclick="changeParentValueInParallel();" value="Click me"/>

</body>
</html>

Here are the steps to reproducing the concurrency. Open the page, then on the parent page there will be an alert - DO NOT CLICK OK, go into the newly opened page (child) and click the button. Then click OK on the parent page. What you will see in IE and Opera (FF behaves in what I consider to be correct behavior) is the parent's window value be changed by the child while I am still in the function. Alas, this is exactly what parallel execution is, and thus the need for mutex (or some other mechanism). I don't think I have to explain how this can damage code, this is fairly standard textbook.

It is my guestimate that the XTR objects and ActiveX behave the same way in IE as well as Opera (does anyone have access to Safari at the moment to test this).

Julio, I am not sure how a simple flag would be able to help here. Would love to know what other ways other than mutex implementation would work here to prevent this sort of thing in critical sections. By the way, the mutex implementation is only 30 lines (not 10,000 as you say).

Everyone, please chime in here this is fairly important (I think).

Alex

Re: Mutex + Javascript in AJAX rtm?

LudovicoVan — Tue, 21 Nov 2006 11:17:43 GMT

Oh yeah: BTW, the fileRef variable you can see there is a perfect instance of the "flags" I was talking about above.

-LV

Re: Mutex + Javascript in AJAX rtm?

LudovicoVan — Tue, 21 Nov 2006 11:04:29 GMT

For reference, I'll give a sample about where a timing issue can occur and how easy it is to prevent any problem in idiomatic JS.

The full source is here: http://forums.asp.net/ShowPost.aspx?PostID=1456947

Once you have got what that does, just focus on this simple fragment:

   // Keep order!
   fileDsp.innerHTML = "<em>Loading...</em>";

   fileImg.src = fileBox.value;
   //

Since this code is loading a local file*, assigning to the src property of the image immediately triggers the onload event for the image. But assigning to the innerHTML property too enqueues an interface update. Bottom line, if you revert the order of the statements above, you do not get correct results, because the sequence in which you enqueue events is the sequence in which they get then run!!!

And, this is true for JS in web pages as well as it is true for any ECMA-based language, like it was JS in VRML, like it is AS in Flash, and so on.

I hope this can shed a bit more light, anyway if you guys have any significant sample that you would like to see analyzed and refactored to "true" JS, please don't be shy and post it. IMHO, it might be a very instructive "case-study" for everybody trying to find their way with client-side programming.

-LV

*If the file was not local, the timing issue involved might not show up. Yet, that is the way to go in general, for robust JS programming... We don't need mutexes, neither we miss OO-JS. We better simply know our language...