Discussions

News: Onjava Article: 'Implementing Mutual Exclusion for AJAX'

Bookmark and Share Get thread feed

  1. Onjava Article: 'Implementing Mutual Exclusion for AJAX' (10 messages)

    In "Implementing Mutual Exclusion for AJAX," author Bruce Wallace offers a mutex implementation in JavaScript to handle concurrent access of DOM resources, a problem that's hard to reproduce and even harder to solve. With AJAX becoming more and more mainstream, techniques like this will become very valuable.

    The mutex is based off of the common Command design pattern, and the article walks through an implementation of ,a href="http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm">Lamport's bakery algorithm</a>, which "works for multiple competing threads of control when the only communication between them is shared memory (i.e., no special mechanisms like semaphores, atomic set-and-test, etc. are required). The metaphor for this algorithm is a bakery that requires customers to take a number and wait until their number is called. The skeleton of the algorithm is in Listing 1 and it enables each thread to go into and out of critical sections without conflict."

    From the article's conclusion:
    With AJAX and RIA, the impetus to build complicated dynamic user interfaces is driving developers to use the same design patterns (e.g. Model-View-Controller) formerly tied to "fat" GUI clients. With Views and Controllers being defined modularly, each with their own events and event handlers (but sharing common data models), the potential for conflicts multiply. By encapsulating event handling logic into Command classes, not only can the Wallace variation be employed, but the stage is also set to provide rich undo/redo functionality, scripting interfaces, and unit test instrumentation.
    Reply to this

    Threaded Messages (10)

  2. what for[ Go to top ]

    works for multiple competing threads of control when the only communication between them is shared memory

    LOL. It would be a great job if JavaScript was not single threaded :)
    Reply to this Reply to original

  3. what for[ Go to top ]

    it would be a great job if JavaScript was not single threaded :)
    How about async http requests? Or timers?
    Reply to this Reply to original

  4. what for[ Go to top ]

    it would be a great job if JavaScript was not single threaded :)
    How about async http requests? Or timers?
    Ajax is multi threaded, timers are not.
    Reply to this Reply to original

  5. what for[ Go to top ]

    Ajax is multi threaded, timers are not.

    HttpXmlRequest is multithreaded, but not its js callbacks

    http://ajaxian.com/archives/ajax-from-scratch-implementing-mutual-exclusion-in-javascript
    "are you confusing server requests and threads with browser JavaScript threads? A browser may download multiple objects at once from a server. That doesn’t imply that JavaScript code in that browser runs in multiple threads."
    Reply to this Reply to original

  6. what for[ Go to top ]

    Ajax is multi threaded, timers are not.
    HttpXmlRequest is multithreaded, but not its js callbackshttp://ajaxian.com/archives/ajax-from-scratch-implementing-mutual-exclusion-in-javascript"are you confusing server requests and threads with browser JavaScript threads? A browser may download multiple objects at once from a server. That doesn’t imply that JavaScript code in that browser runs in multiple threads."

    Good question, I thought the callbacks also ran asynchronously. If not the entire idea of having mutexes in javascript is rather pointless, isn´t it, unless javascript can interfere in currently running function/method code with a break in between (sort of like cooperative multithreading)
    Reply to this Reply to original

  7. what for[ Go to top ]

    Ajax is multi threaded, timers are not.
    HttpXmlRequest is multithreaded, but not its js callbackshttp://ajaxian.com/archives/ajax-from-scratch-implementing-mutual-exclusion-in-javascript"are you confusing server requests and threads with browser JavaScript threads? A browser may download multiple objects at once from a server. That doesn’t imply that JavaScript code in that browser runs in multiple threads."
    Good question, I thought the callbacks also ran asynchronously. If not the entire idea of having mutexes in javascript is rather pointless, isn´t it, unless javascript can interfere in currently running function/method code with a break in between (sort of like cooperative multithreading)

    I seem to remember, (don't quote me on this - and things like this do change) that UI events and timers all happen on the same thread. So if you set a timer within an event handler, the timer will not happen until the handler returns. However, you do get different threads running in different frames. So if you call out into another frame in the frameset it can be running there at the same time as that frames own thread.
    Reply to this Reply to original

  8. what for[ Go to top ]

    However, you do get different threads running in different frames. So if you call out into another frame in the frameset it can be running there at the same time as that frames own thread.

    Well I've tried it, and I can't get two threads running the same frame in IE or FF. Please consider my comments above to have been made completely through my hat. It looks to me like you are not in any real danger of getting two threads from different frames competing for variables.
    Reply to this Reply to original

  9. what for[ Go to top ]

    Good question, I thought the callbacks also ran asynchronously. If not the entire idea of having mutexes in javascript is rather pointless, isn´t it, unless javascript can interfere in currently running function/method code with a break in between (sort of like cooperative multithreading)

    Of course it's still fab for multi frame (or hidden frame) applications which are multithreaded. We had a nightmare of a time working on a public display application which had a controller frame for monitoring changes and cycling the display frame. Having to provide all the threading symantics without having built in mutexes was painful.

    The client specified Javascript for this btw. not the development team :-)
    Reply to this Reply to original

  10. Says who?[ Go to top ]

    Try as I might, I cant find anything on MSDN that says anything definitive about how JScript is implemented on IE with regard to threading issues. What is the URL of the definitive threading specifications that Microsoft promises to implement?
    Reply to this Reply to original

  11. Errr....[ Go to top ]

    The Mutex class itself isn't thread safe.
    Reply to this Reply to original