and in your example the thread is not idle because is stuck in your
endless and freezing cycle.
On Sunday, September 19, 2010, Johannes Lehmann
<johannes.lehmann1@googlemail.com> wrote:
> I appreciate that with JavaScript interpreters executing in one thread
> there will never be any *true* concurrency. However it seems perfectly
> possible for concurrency issues to arise with the way that
> asynchronous callbacks are used A simple example is if I am
> continuously checking the value of a variable x, and then incrementing
> it:
> while(!stop) {
> int i = x;
> x = i+1;
> }
>
> Once the event occurs, the handler prints the variable and sets a flag
> that causes the incrementing to stop:
> print(x);
> stop = true;
>
> The intended behavior might be that the final value of the counter is
> printed. However if the event handler is invoked right after the
> assignment 'int i = x', the value will be incremented one more time
> after it is printed, which is a concurrency bug.
>
> In such cases the synchronized keyword could have been used to define
> pieces of code which must not be interrupted by other pieces of code
> in such way. In plain Java the synchronized keyword provides an easy
> way of dealing with such issues. The problem I described in my first
> post is very similar to this in nature and I am lost as to what to do.
>
> I hope this makes what I mean a bit clearer. Of course I am not
> excluding the possibility that I just misunderstood somthing about how
> the GWT/JavaScript eventing mechanism works.
>
> Thanks,
>
> Johannes
>
> On Sep 17, 5:40 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
>> On Sep 17, 4:13 pm, Johannes Lehmann
>>
>> <johannes.lehma...@googlemail.com> wrote:
>> > OK, that is basically what I assumed. This however seems to create
>> > concurrency issues, which the synchronized keyword was designed to
>> > address. Without any language support such as semaphores or mutexes
>> > and without any guarantees regarding preemption, how could I solve a
>> > problem such as the above?
>>
>> Excuse my ignorance about semaphores/mutexes/preemption details, but
>> how can there be concurrency issues if things never execute
>> concurrently? (and *your* code will never execute concurrently with
>> *your* code)
>>
>> If you really want the gory details:http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapi...
>
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-web-toolkit@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
--
*Stefano Ciccarelli*
stefano@indacosoftware.it
*Indaco srl*
via Sabin, 22 - 40017 San Giovanni in Persiceto (BO) - Italy
tel. +39.051.827762 - fax +39.051.6874570
info@indacosoftware.it
www.indacosoftware.it
*- This e-mail is confidential and may be read, copied and used only by the
intended recipient. If you have received it in error, please contact the
sender immediately by return e-mail. Please then delete the e-mail and do
not disclose its contents to any other person.
- Le informazioni contenute in questa comunicazione sono riservate e
destinate esclusivamente alla/e persona/e o all'ente sopra indicati. E'
vietato ai soggetti diversi dai destinatari qualsiasi uso, copia, diffusione
di quanto in esso contenuto sia ai sensi dell'art. 616 c.p., sia ai sensi
del DL n. 196/03. Se questa comunicazione Vi e' pervenuta per errore, Vi
preghiamo di rispondere a questa e-mail e successivamente cancellarla dal
Vostro sistema.*
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment