Win a copy of Beginning Java 17 Fundamentals: Object-Oriented Programming in Java 17 this week in the Java in General forum!

Aleksey Vladimirovich

Ranch Hand
+ Follow
since Sep 05, 2012
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
2
Received in last 30 days
0
Total given
9
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Aleksey Vladimirovich

Winston Gutkowski wrote:

Aleksey Vladimirovich wrote:As for images - they are sort of small logos (about 2K each) and there is nothing to do with them...I mean as a programmer I cannot save memory on them, unlike these inefficient collections, but I guess I just have to accept it.


Well, for starters, those collections are only time inefficient, because they're synchronized when there's often no need. I doubt whether there's very much difference (if any) in space efficiency between them and the newer types. The basic overhead is for the collection object itself (maybe 20-30 bytes) and a dozen or so for each element because it must be an object. Hashtables will also have an overhead for the internal bucket store; however, since each of your objects is already 2K it's likely to be a drop in the ocean.

HIH

Winston



Yea, I'm aware that they are time inefficient because of being synchronized, but for some reason I thought, in addition to that they consume large amounts of memory, you just opened my eyes. The collections are still bothering me, but at least I've learnt something new, thank you
9 years ago

Winston Gutkowski wrote:Then I'm not quite sure what your question is. The Thread is the thing that needs to do the notification, so just register it with your Observable (presumably your cache of images) and notify it that it's complete.


The problem is in absense of experience in java Now it works fine - once the image is downloaded the thread tells another object to redraw graphics of a widget, everything seems to work smoothly.

Winston Gutkowski wrote:What overhead? The image itself is likely to be far bigger than anything else you need to concern yourself with.
But, as I say, maybe I'm just being thick and don't follow what your problem is.


Sorry, maybe my posts were a bit misleading...I'm concerned about the collections not only in this particular piece of code, but all over my app, it has to process pretty big amounts of data (at least as for mobile device) and I have to use these old collections on and on since I don't have alternatives. As for images - they are sort of small logos (about 2K each) and there is nothing to do with them...I mean as a programmer I cannot save memory on them, unlike these inefficient collections, but I guess I just have to accept it.
9 years ago

Winston Gutkowski wrote:
But Vector and Hashtable are? That would suggest to me that J2ME is many versions behind Java SE, which strikes me as a problem right there.

I wonder also if threading isn't a red herring here. If you want something notified of a change, my suggestion would be to implement the Observable/Observer pattern. Then you can implement any kind of notification you want.


Well, it is far behind J2SE and it sucks J2ME is very primitive and in addition to that it is not open source. Sorry, I'm not sure what "red herring" mean, but if you meant "excessive" than the answer is no, I wanted to implement lazy image downloader and there is no way to do it without threading. And yes, I've used the Observer pattern here, it works fine, but I'm still worring about memory overhead...I guess there is nothing I can do here though.
9 years ago

Jesper de Jong wrote:ArrayList and HashMap instead of Vector and Hashtable.

But since you didn't mention until now that you're working on Java ME, Steve ofcourse didn't know that you can't use those because they're not there in the library for Java ME.


Yea, I'm aware of these collections and it's a shame that they're not available in J2ME, I just thought maybe there were any alternatives of ones in J2ME.
9 years ago
Thank you, Steve for such a good explanation, I appreciate it

Vector was bad in Java 1.4 - much better tools where available then, so this is not a good excuse for using Vector.


I still haven't figured out what tools were you talking about. I want to get rid of synchronized collections like Vector and Hashtable so badly, but I can't find any alternatives in java me (yeah, that's probably a detail I should have mentioned in the beginning of the post, sorry) Anyways, if it's possible, please give me some tips
9 years ago

Steve Luke wrote:The short answer is there are dozens of ways of making one thread wait for another thread. The question is, why doesn't wait()/notify() work for you? Knowing that will help determine which is the best route to take.


No-no, wait() is okay, the thing is to wake a thread with my own method (not notify()). I'll explain why I need it: I've created a class ImageDownloader, which has to work then and only then when it has objects waiting for images to be downloaded, here is an example:

Please ignore the Vector collection (I know it's not good), unfortunately I have to deal with old java 1.4 here
So I want my loader to wake up by triggering addListener() method. Is it possible?
9 years ago
Hi guys! Could you please tell me if there are any other possible ways to wake up a thread besides calling notify() or notifyAll() on it? I need my thread to wait and then be awoken by calling my own method... Is it possible?
9 years ago

Joanne Neal wrote:

Aleksey Vladimirovich wrote:You're saying that the parent thread waits for a response from each thread, join() method was called on, and only then does the same to the next thread (second child won't start until first is done), right? In that case there is no point in it


You store a reference to each thread in a collection. You then loop through the collection and call start on each thread. So all your threads are now running. You then loop through the collection again and call join on each thread. The call to join on the first thread won't return until the thread has completed, but during this time all the other threads are running as well. Once the call to join on the first thread returns, you call join on the second thread. It may be that the second thread has already completed, so join will return immediately but if it hasn't join will not return until it has. This repeats for all the threads in your loop.


Thanks a lot! Now I get it! Everything works how it supposed to
9 years ago

Jesper de Jong wrote:You start a number of threads, so you have a collection of Thread objects. Then you just loop over those Thread objects and call join() on each of them in the loop.

If the thread you call it on has already stopped, join() returns immediately. If it's still running, join() waits until the thread has stopped.

So if you call it in a loop on all Thread objects, then when the loop is done, all those threads have stopped.


Oh, in that case it's not what I need I need all child threads run simultaneously, not sequentally... Or maybe I understood you wrong. You're saying that the parent thread waits for a response from each thread, join() method was called on, and only then does the same to the next thread (second child won't start until first is done), right? In that case there is no point in it
9 years ago
Um, sorry for annoying you guys, but could anyone please explain me, how does join() works? I mean, if it makes parent thread to wait until children threads die how can I call join on the other threads besides first one? Or the method of parent thread keeps executing to the end and then when all children threads are done it triggers that method from the point where the last join(0 was called?
9 years ago

Jayesh A Lalwani wrote:Since executor service is not available to you, you are better off implementing your own executor service. You can use a publisher consumer pattern. Have a queue that holds your jobs. The main thread posts jobs to the queue, and the worker threads takes jobs from the queue and process them. Have another queue that holds results, and the worker threads can posts results to the result queue as they finish a job. The main thread can monitor size of the queues. Once the results queue have all the results, take them out and process them.


Actually I was intended to do that, thanks!
9 years ago
Thank you, guys! join() worked like a charm!
9 years ago

Jesper de Jong wrote:Your "small remark" changes the whole question...
If you have multiple threads doing the work, you could use a CountDownLatch. Create it with a starting number, the number of tasks that has to be performed. In the computation thread, count down the latch by one when the task is finished. In the main thread, make it wait until the CountDownLatch reaches zero (it has special methods for that). When it reaches zero, all tasks are done and you can collect the result.


Unfortunately I have to work with ancient java 1.4 version in this particular case and there was no CountDownLatch in it, it is available since version 1.5.
9 years ago

Joanne Neal wrote:

Aleksey Vladimirovich wrote:Oh, small remark: the reason to call Thread2 and make Thread1 to wait is that in real code there will be N (N > 1) child threads, each doing it's own job. And once all child threads are done, parent thread sould wake up and do it's job.


So if the parent thread doesn't need to do anything until all the child threads have completed why don't you just get the parent thread to call join on each of the children after it has started them ?


Sorry, I'm noob in Java. So, if I call join on all child threads, I'll be able to get data from them? I mean the parent thread won't wake up until all of them are finished? And here is what java docs say: "join() - Waits for this thread to die." So will I be able to get my data from them?
9 years ago