• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Future and Callable Doubt

 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ,

I am new to Concurrent Multithreading in java .Some of my doubts may seem minor .Actually i have doubts related to internal working of Futures and Callable.

We use Future.get() to get the call() results . Suppose we have multiple threads in our program where suppose First thread is taking 15-20 min to execute . then in that case the other thread which is trying to execute does Future.get() will have to wait for first one to complete . Because in Future.get() documentation it is written for get() documentation [Waits if necessary for the computation to complete, and then retrieves its result.] .

So I am confused with this statement that wait will happen across threads and if its the case then how this Future and Callable adding value ??

 
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mohit,

your understanding of Future.get() is correct. Calling get() will block your current thread until the computation is finished (additionally you can specify a timeout). So obviously it wouldn't give you any advantages to make some computations in a background thread and block your main thread by waiting on the result from the background thread. This would be similar to simply doing all the work directly in your main thread.

But it really depends on the problem you are trying to solve what a good solution could look like. Java offers a lot more helpful classes and tools for concurrent applications. For example an can be very helpful if you can break down your problem at hand into many smaller problems which can be solved in parallel. But of course this will only work if the smaller problems don't depend on each other and so.

Unfortunately this topic is way too complicated to discuss all the possibilites here. Therefore to give you better advices it would be very helpful to let us know what problem you are trying to solve ;-)

Marco
 
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You would do better to find a book or the Java® Tutorials.

This forum is for asking questions about the Ranch itself, so I shall move this discussion somewhere more appropriate.
 
Mohit Chauhan
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Marco,

Thanks for your quick and valuable response .

Actually i am using Future , Callable in Cache implementation.
I am using map as a cache which can be searched instead of going to particular implementations.

Code is as below :


In Memoizer3 particularly in compute(A) . Here if value is not in cache then cretea it and put it in cache otherwise if value was already there in cache then directly take that value.

There can be a case where first thread passes the check that value is not in cache and tries to get it from actual implementation , and in the mean time i have some other thread which also try to access the same code .Now there can be possibility that second thread which is querying for the same A object but since we didn;t reached a point where we add required value in cache map during first thread execution
This will lead to case where value is not present in map but it is in the process of being added .So this will actually lead to a case where values will be taken from direct implementation instead of cache, which is not correct .

ie :
t1 => compute(A1);
t2 => compute(A1);

So in this context i want to know will future.get save us from it ?

[Above complete code can be found at Java Concurrency in Practice Pgno-74 ebook]
 
Marco Ehrentreich
best scout
Posts: 1294
Scala IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mohit,

I think using Futures this way just complicates your implementation and doesn't have any advantages ;-)

If you really want to implement something like a cache yourself than it could be enough to use an ordinary ConcurrentHashMap for this purpose. With Java 8 it has even more nice features. I guess you'll find enough examples on Google.

Anyway, you probably should consider to use an existing caching framework or something like that for production use!


Marco


 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

On a previous train of thought...

Marco Ehrentreich wrote:
your understanding of Future.get() is correct. Calling get() will block your current thread until the computation is finished (additionally you can specify a timeout).



Additionally, if you don't want to call get() when the result isn't available yet, you can also call the isDone() method to check first. This way, your thread won't block on calculations still in progress, and can move on to doing something else.

Henry
 
Mohit Chauhan
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Henry,

It means if i have three threads being executed through Callable/Future service and if first thread is taking much longer , keeping a check early on future with isDone() makes my other threads to work without any blocking or waiting for first thread results.

However if i use the same implementation without isDone() , then my run will be stuck until first thread completes and gets result ?
 
Henry Wong
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mohit Chauhan wrote:
It means if i have three threads being executed through Callable/Future service and if first thread is taking much longer , keeping a check early on future with isDone() makes my other threads to work without any blocking or waiting for first thread results.

However if i use the same implementation without isDone() , then my run will be stuck until first thread completes and gets result ?



I don't understand the concern here. You have a bunch of threads, and either ... they need each others result or they don't (or likely a combination of both). If they have stuff to do that don't require the other's result, then do those first. Why wait for data until you need it? And if they need the result of each other's thread, then they have no choice. Threads may have dependencies and that can lose parallelism -- this isn't any different.

Henry
 
Mohit Chauhan
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I am aware of Callable and Future working on the outer side . Can somebody please give an overview , which locking mechanisam it internally uses (is it synchronisation or some other ).

Also while going through internals of Executor service where we use Callable-Future combination.While submitting calllables we are internally using Reentrant Locks while creating those threads.
Are we using the some Locking technique ??



Thanks
Mohit Gupta
reply
    Bookmark Topic Watch Topic
  • New Topic