Garik Ustinov

Ranch Hand
+ Follow
since Jun 22, 2009
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Garik Ustinov



just make sure you never code like that
10 years ago
I think all implementations of Collection have a constructor, which takes another Collection and adds all the elements to the new object, like new ArrayList(someHashSet).
Speaking of Map type, we have a problem, since Map is not a Collection and it's entry needs two things - key and value, while Collections can provide only one element, so you have to populate a Map manually.
10 years ago
You might be interested in java.util.concurrent package. There is plenty of stuff for asynchronous processing. For example, implementations of Future interface provide the sort of functionality you're asking for
10 years ago

as I don't know the latest Spring (or whatever) framework


It's impossible to know every framework which is hot on the market now. But, as pointed out above, SCJD assignment is a very good exercise. It's time-consuming, and sometimes even frustrating (currently I'm in the middle of exciting process called "waiting for results" ), but you learn a lot indeed and well there's more fun writing some working stuff rather than filling out those dull multi-choice questions.
Some time ago I wasn't dealing with heavy multithreading myself, but when my cert app was almost ready, I got a new work assignment and guess what, it was ALL about multithreading. So my 2 cents would be go for SCJD

Henry Wong wrote:
I thought that the example provided (and asked about) was about two different instances, aObject and bObject


Well, I was talking about accessing the shared Vector by multiple threads. Apologies if any confusion caused

Henry Wong wrote:
It is definitely in the order of less than 100 nanos.


Indeed. But I thought the performance question was "Why" not "How bad"
Still, it's a bad idea to use Vectors throughout the application if performance matters since even nanoseconds tend to accumulate.
10 years ago

thread1 can update "aObject" parallely when thread2 updates "bObject"


don't confuse multithreading with parallelism. Vector is designed for multithreaded access (multiple threads are able to use the same Vector instance safely), but it is not suitable for parallel (concurrent) processing, i.e. multiple threads cannot access it's methods simultaneously.
ThreadOne cannot call vector.get(0) while ThreadTwo calling vector.get(1) - someone will have to wait. In fact there's no way to execute any Vector methods in parallel.
And it is slower that ArrayList for example because synchronization means some additional overhead associated with acquiring the lock. So ArrayList works faster but it cannot be accessed by multiple threads at all (unless you provide some external locking).
10 years ago

Fiorenza Oppici wrote:
how can the compiler recognize the package version in java class??



For the compiler it's not a problem at all. You might be interested in this
10 years ago
You have 4 Threads working together without a single synchronized block, concurrency api usage or even volatile variable. I guess it just cannot be right. Take a closer look, maybe there's something wrong with it.
There are plenty of Producer-consumer examples java producer consumer available. I suggest you to start with some simpler examples, rather than digging in Java Concurrency in Practice.

Neil Cartmell wrote: For now i'll maybe just use fewer words.



Yup, it's not the best practice to hard-code a huge amount of data, presuming that the largest part of it won't be needed. It's not about memory (however, of course at some point it'll start to matter), but about style. Create a WordFactory class or interface, hard-code some words for testing and then as soon as you're comfortable with file IO (which isn't too hard) replace the implementation. Goodluck
10 years ago
But why do you need to store all 600+ words in memory since you need only one word per game? what if you create a text or xml file and store everything you need there. Then, as soon as the new game starts pick one random word and present it to the player.
10 years ago
Yes, it is allowed to do it this way in order to achieve backward compatibility with previous Java versions.
And no, you don't want to code like this.
Consider the following:


The compiler would be happy to compile this, but guess what you get in List<String>? An object!
By declaring a Collection<String>, you want to be sure that you get only Strings in there, while a raw type collections allow you to add anything. One day after refactoring your new ArrayList() will be returned from a separate method. Maybe the next day someone will add something to it and who knows, maybe this something won't be a String...
10 years ago

Now, what would happen if both are used together


I would say nothing disastrous. Lets say we have threads A and B synchronized on common object. Thread A sleeps and then waits. They both will simply do nothing during sleep and then as soon as wait phase starts, the action resumes (in thread B). Probably such a combination might be even used for some fine-tuned thread orchestration, for example if you want to do some processing in thread B in some period of time (on the other hand, it would make much more sense to put sleep() in thread B in this case).

synchronization needs to be called at the method level of the object


Actually I am interested in this question myself. In fact I discovered recently that in C# it is not recommended to declare public methods as synchronized (as well as using this as a monitor lock, instead it is encouraged to use lock() (which is equivalent to synchronized block in Java) on some other object whenever possible. The reason is simple. If you declare public non-static method as synchronized, somewhere else the object which has these methods might be used as a monitor lock itself. This can be quite confusing, one can easily "lose" the track of locks and end up in something terrible like deadlock.
I think the main idea is to keep things as simple for reviewers as possible. Sometimes synchronized methods are fine, in other situations it is better to introduce a dummy private object and use it as a monitor lock.

How did scientists came to be aware of the existence of machine language?


Well, according to Plato, apparently the early programmers discovered it while they were having a party in some Greek cave, but there's no historical evidence about that.

As you pointed out already, it's related to the technical evolution and shifting programming paradigms from the early days when programmers manually (meaning with their hands) controlled the processing unit up to nowadays when modern IDEs are often outsmart their users. You might want to take a look here - History of programming languages
10 years ago
I think having a number of functions with meaningless names doesn't help with code readability. I would do all the calculations in one method. Alright, two - one would be needed for factorial operation, which by the way can be nicely calculated via recursion java factorial recursive
10 years ago
If I recall correctly, static and non-static synchronized methods are synchronized on different object, in the latter case it's "this", while in the former it's a class. So these two methods are not really synchronized against each other whatsoever.
Speaking of Scenario 2, these methods are synchronized on "this" so there's no way for them to acquire the lock at the same time a someone will have to wait.