| Concurrency Support [message #51941] |
Sat, 29 October 2005 11:43  |
Eclipse User |
|
|
|
Originally posted by: mikhail_kimmelman.hotmail.com
Does OSGi/Equinox provide any support for concurrency and asynchronous
exchange data between services ?
Misha
|
|
|
| Re: Concurrency Support [message #52153 is a reply to message #51941] |
Wed, 02 November 2005 03:27  |
| Eclipse User |
|
|
|
Originally posted by: jeff_nospam_mcaffer.ca.ibm.com
Not sure exactly what you are after here but the Eclipse Jobs API does a
mess of concurrency stuff. That function is in the current Runtime plugin
(org.eclipse.core.runtime) but will be moved to its own plugin in the next
week or two.
Jeff
"Mikhail Kimmelman" <mikhail_kimmelman@hotmail.com> wrote in message
news:djvn3l$npb$1@news.eclipse.org...
> Does OSGi/Equinox provide any support for concurrency and asynchronous
> exchange data between services ?
>
> Misha
>
|
|
|
| Re: Concurrency Support [message #52206 is a reply to message #52153] |
Wed, 02 November 2005 07:11 |
| Eclipse User |
|
|
|
Originally posted by: mikhail_kimmelman.hotmail.com
"Jeff McAffer" <jeff_nospam_mcaffer@ca.ibm.com> wrote in message
news:dk9bla$fvc$1@news.eclipse.org...
> Not sure exactly what you are after here but the Eclipse Jobs API does a
> mess of concurrency stuff. That function is in the current Runtime plugin
> (org.eclipse.core.runtime) but will be moved to its own plugin in the next
> week or two.
Thank you for your response.
To be more specific I consider using Equinox (not the entire RCP)
as a foundation for a simple java GUI application.
The application is just a regular "fat" client which consists of GUI,
business logic, and communication modules that run concurrently and
exchange data with each other in both synchronous and asynchronous
mode.
So, I wonder if OSGi/Equinox provides an infrastructure to run
"services"
concurrently, and call them asynchronously.
I have looked through the Eclipse Jobs API and found them a bit
inconvenient
but that may be just a matter of taste. Usually I use another approach:
concurrent
components (e.g. Eclipse "Jobs") have their own message queues
("mailboxes"),
a mailbox per job. Thus the jobs exchange messages with each other instead
of
working with shared memory using ILock. I am discussing it in the "rcp"
newsgroup.
Misha
|
|
|
| Re: Concurrency Support [message #52231 is a reply to message #52206] |
Wed, 02 November 2005 09:40 |
| Eclipse User |
|
|
|
Originally posted by: stepper.sympedia.de
Mikhail,
Your message queues are nothing else than pieces of shared memory plus "locks".
The Jdk1.5 has great support for concurrency, including ThreadPools, Future values and so on.
Look into the java.util.concurrent packages. You'll also find your BlockingQueue...
Btw. in my opinion it is better to leave the decision whether to call synchronously
or to call asynchronously to the caller rather than to the callee. The reusibility
of the callee component is somewhat bigger then. On the other hand you have more
manual work in the caller in the event that it needs to call asynchronously.
This is a matter of taste and might be influenced by the ratio of a- and synchronous calls.
Cheers
/Eike
Mikhail Kimmelman schrieb:
>
> "Jeff McAffer" <jeff_nospam_mcaffer@ca.ibm.com> wrote in message
> news:dk9bla$fvc$1@news.eclipse.org...
>
>> Not sure exactly what you are after here but the Eclipse Jobs API does a
>> mess of concurrency stuff. That function is in the current Runtime
>> plugin
>> (org.eclipse.core.runtime) but will be moved to its own plugin in the
>> next
>> week or two.
>
>
> Thank you for your response.
>
> To be more specific I consider using Equinox (not the entire RCP)
> as a foundation for a simple java GUI application.
>
> The application is just a regular "fat" client which consists of GUI,
> business logic, and communication modules that run concurrently and
> exchange data with each other in both synchronous and asynchronous
> mode.
>
> So, I wonder if OSGi/Equinox provides an infrastructure to run
> "services"
> concurrently, and call them asynchronously.
>
> I have looked through the Eclipse Jobs API and found them a bit
> inconvenient
> but that may be just a matter of taste. Usually I use another approach:
> concurrent
> components (e.g. Eclipse "Jobs") have their own message queues
> ("mailboxes"),
> a mailbox per job. Thus the jobs exchange messages with each other
> instead of
> working with shared memory using ILock. I am discussing it in the "rcp"
> newsgroup.
>
> Misha
|
|
|
| Re: Concurrency Support [message #52337 is a reply to message #52231] |
Wed, 02 November 2005 21:32 |
| Eclipse User |
|
|
|
Originally posted by: mikhail_kimmelman.hotmail.com
"Eike Stepper" <stepper@sympedia.de> wrote in message
news:dka1d9$7fb$1@news.eclipse.org...
> Your message queues are nothing else than pieces of shared memory
> plus "locks".
> The Jdk1.5 has great support for concurrency, including ThreadPools,
> Future values and so on.
> Look into the java.util.concurrent packages. You'll also find your
> BlockingQueue...
Yes, I know this package. Implementing thread pools, futures,
asynchronous calls, etc. is not a problem now. The problem is
a lack of common unified infrastructure for that stuff.
Let's say I have a service which calls another service asynchronously.
There is no standard way to do that. I have to implement it on my own
in my own way. Thus, my components will not be integrated easily with
components of other programmers.
BTW from this point of view Eclipse Job API including Job, ILock, etc.
is not enough in my opinion.
Misha
|
|
|
Powered by
FUDForum. Page generated in 0.03317 seconds
] 
Search
Help
Register
Login
Home
