Alexander Kober

Ranch Hand
+ Follow
since Aug 05, 2011
Alexander likes ...
Scala IntelliJ IDE Java
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Alexander Kober

Standard race condition:

+ T0 and T1 both enter the for loop and execute #8.
+ T0 executes the (++i) in #9 and increments the shared variable.
+ T1 executes the (++i) in #9 as well as the println(...)
+ T0 executes the println(...) in #9.

All you have to keep in mind here is that expressions are evaluated from inside to outside. println(++i) is executed as 1. (++i); 2. println(...);

It is very important to know what operations are executed atomically (as in: This statement executes fully or it doesn't, but there are no intermediate states). By that definition, and this is a common pitfall for people new to threading, (i++) is not atomic either, as it is a shorthand for 1. get i, 2. increment what you got, 3. write the result to i.

Scott Kimberly wrote:

So how much of that is one method? It sounds like 1-4 is one method and 5 is a second.

Also I want to createImage and use that instead of BufferedImage for reading in my sprites?

Then create a Graphics2d object and render all my sprites to that object.

And when i dispose of my Graphics2D itll still draw it, disposing just dumps it from memory right? Sends it to garbage collection?

Sorry if that was confusing. The method you'll have to run whenever your panel size changes is of course the one where you create the image buffer and draw your sprites - so yes, points 1 to 4.

The way you're reading your sprite images is fine - JComponent#createImage simply makes sure that the image buffer you create for your sprites is 'compatible'. In simplest terms, this means that the image's color model is one that the graphics card understands and does not have to be converted internally before drawing it to the screen. Since you'll only draw the sprite images onto your image buffer once, their model doesn't really matter.

Disposing a Graphics2D indeed only releases the associated resources - since the Graphics2D instance has some counter parts in native drawing code, it is good practice to do so. Your image will not be affected in any way.

9 years ago

Scott Kimberly wrote:
Is there a way for my to add all the sprites (the final map image) into a Swing Component and then just display that component rather then draw out the entire thing? If so, which one would be the best at handling it? I really dont need the entire thing to be redrawn, i just need it made once for now.

Sounds like what you are looking for is simply a buffer for your background image. You can easily use the BufferedImage class to achieve this. In your spriteRiverSetup method
1. Create a BufferedImage of the appropriate size (same size as your panel will be). Best do this using JComponent#createImage(...);
2. Invoke image.createGraphics to obtain a Graphics2D object.
3. Render all your sprites to the image, pretty much the same way you did in your paintComponent method now
4. Dispose of the Graphics2D instance (graphics.dispose()).
5. In your paintComponent method, simply draw your image to your component (this is very, very fast).

You will, of course, have to rerun the method if your panel's size changes.
9 years ago

Karan Hans wrote:what does the following staement mean:
The main() method is static but swing frames are objects so you have to figure how to get your program out of static context. This can be done by creating the application as a class that extends JFrame. the main method then calls the class constructor in effect creating an instance of itself.

Are you familiar with the concept of static methods and their scope?

Basically, all the above is saying that in a class

you can't invoke setVisible(boolean) from the main method as JFrame#setVisible(boolean) is bound to an instance of JFrame while you're running within the class' static scope. What you need to do is instanciate MyApp first:

Note: The actually correct way would be to invoke setVisible from the EDT, but i didn't want to make the example more complicated.
9 years ago
There are at least two things wrong with the implementation:

1) It seems you start a thread and immediately expect it to be running. This is not the case. Thread#start schedules a thread for execution, but that may happen at any time. Usually, thread startup will happen very fast, but not immediately.
2) Though this is may be unintuitive, never use a plain boolean for synchronization between threads, at the very least make it volatile or use an AtomicBoolean.

That being said, if I understand your code correctly, you simply want to block key input for 2 seconds, correct? Why create a thread in the first place then? When your keyPressed method is executed, take the current system time (System.currentTimeMillis()) and assign it to a variable. Simply add a check at the beginning of the method to see when the last keyPress was processed:

mozammil muzza wrote:Hi All,
Do we have any java API to interact with hardware like c, c++ ?

There's three things that come to mind:
1) Most hardware devices will come with a DLL/so/dylib. You can use the beforementioned JNA project to access them. Unless you absolutely require the last bit of performance (which would require you to use JNI), JNA is perfectly suitable for most applications and, as you requested, pure java.
2) Check out rxtx for working with serial/parallel ports. A lot of devices will emulate a serial port and can be accessed with this tool, too.
3) For directly accessing USB devices, take a look at libusbjava.

Other specialized hardware may actually require some C level code though.
9 years ago

Kedar Thakar wrote:Thanks for the reply. In my case I dont know the exact task and its number. Task can be 100 in number or may grow till lacs. In that case what should be my approach. Also, I woluld like to know the approach I took to change the thread size is correct or not?


I have a feeling you might be making a mistake here distinguishing between threads and tasks. Tasks, as in work packages, may be unlimited. The number of threads only determines how many tasks are being worked on at the same time (and, implicitly, how many CPU cores are being used). It is almost generally a bad idea to design a system to have hundreds of active threads, with the exception of few heavy duty server applications. Having significantly more threads than CPU cores will have a severe impact on throughput. The question at hand is: Do you really need the tasks to be run at the same time, or can't you just process them one by one using a smaller number of threads? Or, to be more precise: Will your tasks time out if they're not handled immediately?

Regarding the correctness of your approach: I would not recommend simply 'throwing away' the old executor the way you are now. Also, your method checkTime, at least judging from your pseudo-code, simply measures the time it takes to enqueue the task for the pool. This does not in any way mean that the task is completed when executor.submit(...) returns, only that the executor accepted the task as something to be done at some point.

Jon Swanson wrote:Did I structure this problem wrong? Or do I need some sort of hack like setting a flag before calling the updateWeightPercent() routine and unsetting it when it is finished? I'm leaning that way, but would rather know the right way to handle this sort of thing.

That is actually a feasible approach for what you're trying to do, adding a flag is not a 'dirty hack'. You should, however, make sure to make this flag volatile if you're doing your updates from a worker thread to avoid threading issues.
9 years ago
You're looking in the wrong place.

The wait method is used to synchronize threads, not to delay a user interface update. What you want to do would look more like this:

This example does not consider threading. If this were done in swing, for instance, you'd want to run the entire method on a worker and dispatch showAdvertisement() and hideAdvertisement() on the EDT, but i guess this is going too much into detail.

At Th wrote:Thanks for the info. But this will again hardcoding of the thread size.

Actually, the thread pool described in the answer above will adapt dynamically to the number of jobs, it will just do so based on the number of queued tasks rather than on a fixed interval.

However, let's take one step backwards first. What kind of jobs are you processing? Knowing this is critical, as there are few cases where just increasing the number of threads will actually give you more performance (meaning both latency and throughput), and even then you can't just infinitely scale the number of threads. If you don't know what tasks are being processed, you don't have a solid basis for estimating the optimal number of threads anyway. If you know what is being done, you should be able to find the optimal maximum number of threads based on the number of CPUs in the system (Runtime.getRuntime().availableProcessors()).

Note that you have to escape brackets, otherwise they'll be interpreted as part of the regex. Curly parantheses are used for declaring repetitions. If you want the bracket characters, you have to escape them with a leading \ (which would become \\ when writing a java String). The same is true for the '+' character.
9 years ago
As you can see in line 10, the constructor of class 'Playing' takes a String argument. The field Playing#name is of type Playing.Name, an enum you defined. Java will not automatically convert a String to the corresponding enum value. In line 40, you actually do pass an enum to the constructor, so i guess all you'll want to do is replace line 10 with

9 years ago
Short answer is: a device may be able to run java applications, but a mobile device does not necessarily have the same libraries and surrounding (java runtime) a desktop PC has. Take a look at Java ME for details on development of mobile applications.
9 years ago
I'd also advice reading up on the async I/O features in java 7, which probably won't be covered in too many books, and take a look at the Selector API.
9 years ago
Seems to me this would be the best approach. I'd recommend using a thread pool with a fixed size though - you certainly don't want 5000 concurrent threads in your JVM. The number of threads in the pool does not really depend on the number of users, but on the business logic being performed. You want maximum cpu utilization while avoiding unnecessary context switches, which is a target conflict. Basically, you need to consider how much of your business logic is actual work for the cpu. If your Runnables contain pure number crunching, you'll want one thread per cpu (though this is almost ever the case). If you're doing a lot of I/O, you may want 3 or 4 threads per cpu - it is really impossible to determine the best number without inside knowledge and/or profiling of your code.