Sergey Babkin

+ Follow
since Apr 05, 2010
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 Sergey Babkin

A thing to keep in mind is that synchronized and static synchronized will use different lock: the static methods will use a lock on the class, and the normal methods will use a lock on the instance. So they won't synchronize with each other. If you access the static variables through static synchronized methods, this will make sure that the access to them is synchronized.

An easy way to synchronize in the getInstance() is to do the full initialization of the object before assigning it into the static reference. This way no other thread can see the object until it's initialized.

And finally: don't use singletons. They are a very bad programming practice. Even worse than the simple global variables.
On Unix/Linux the worst that can happen is the "published" file containing an incomplete record. The renaming is atomic, so no problem there. However the writer might open the temporary file, which would then be renamed, so the write will complete after the file has been renamed. Windows is a pain, and likely would not allow to rename the file while it's open.

Ernest Friedman-Hill wrote:Nothing. THere's no difference. "." is just a shortcut for typing "source"

It's actually the other way around :-) "." has been there for a long time, and "source" is a newer longer bash-specific way to write it.
10 years ago
Probably on the first run all the related data and code gets loaded from disk into the caches, and does any other set-up tasks like opening teh connection, compiling the query etc., and then it runs from memory over the already established connection. It happens everywhere, the first time something runs is always slower. You can try to optimize by keeping as much of existing infrastructure open between the calls and reusing it.
10 years ago

Thakur Sachin Singh wrote:but problem is...when i write the data in this file then no data write to this file.

You close them in the backwards order. You need to close dos first, fos last. The way it's now, first you close the file then you close the intermediate filters, telling them to flush the data. They try to flush but the file is already closed, so they have nowhere to write to.
10 years ago
In practice notify() probably already does what you need, at least most of the time. Thinking of how the implementation would work internally, the easiest way would be to make a list of waiting threads, so the wakeup would also go in sequence. Whether the priority would be taken into the account is a separate question, it depends on whether this list building would take the priority into account. And the easiest way is to list the threads regardless of priority :-)

Remember, the scheduler priority matters only between the threads that are ready to run. When the threads are waiting, and one of them is notified, the scheduler policy doesn't apply. It's the internal policy of notify() that matters.

My guess is that the manual says "random thread" to allow the notify() implementations that do or don't take the priority into account.

Try to write a simple program and see what happens. Most likely it already does what you wants (though maybe with some degree of fuzziness).

If you really, really want a strict ordering, you can try something like this:

This way each thread gets its individual notification, and they go in a guaranteed order. The single flag for notification becomes also split per thread. Note that it must be set to false under the common list synchronization to avoid a race.

Gil Steidle wrote:Chris, thanks for the link it helped sink this concept in a little more. Am I correct in saying that even without a notify (or notifyAll) that a lock will be released when a synchronized method or code block finishes? I'll run some tests to find out. But can someone confirm or deny?

Yes, that's what synchronized does: it locks the object's lock on entrance and unlocks it on exit. It does _not_ unlock for sleep(), or reading from sockets, or such. The only exception is wait(), for the duration of which the lock gets unlocked.

Christophe Verré wrote:I see. So there is actually in difference between login via telnet or via ssh. I'll try to find out which script does not get invoked (when I find some time to...)

There is a difference between

ssh server


ssh server command

In the second case the .profile (or whatever exact name your shell uses) is not executed. The first case should be the same as telnet.
10 years ago
Awk // arguments select lines, not sequences inside lines. /a/,/b/ means "start from line containing a and go up to and including the line containing b".

The caveat with the Perl example is that it would only work if there is no \n character in the data you're trying to extract. If this is an issue, and you can afford to read the whole file into memory at once, set

$/ = undef;

(and then return its value back after reading the file).
10 years ago
It's a bit confusing. There are two common meanings to the word "monitor". First, "monitor" is an antique word that means the same as modern "mutex" which is also the same as "lock" (noun). Note that the word "lock" can be used both as a verb and as a noun: you can lock a mutex and unlock a mutex, and lock a lock, and unlock a lock.

Second, in Apache code "monitor" means a combination of a mutex and a condition variable (which is an object that you can use for wait()/notify()). So, technically, the Java objects are monitors in this sense, since you can do both synchronized() (e.g. lock/unlock) and wait()/notify() on them.

And, I guess, third meaning of "monitor", used in this book, is the same as is commonly called "critical section".

Because of this confusion, the word "monitor" is best not to be used.

So, the airplane lavatory is a "critical section": place that normally can be occupied by only person at a time. The lock on the lavatory's door is a "mutex": a device that let's the current occupant to be undisturbed after it's locked and until it's unlocked. If other passengers want to use the lavatory, they find the door locked and queue up waiting for it to get unlocked, taking their turns.
You never start the Output Manager threads. In LineToChar for each input line you create a new OutputManager on the same bufferOut but never start it. So nothing consumes the lines from bufferOut. Creating a thread object doesn't start the thread. And you probably only need to call and start one OutputManager object, not create them every time.

Also, I think there an error in InputManager: to start a thread, use the method start(), do not call directly run(). Run() is just a method like any other, and if you call it directly, it will be executed in your existing thread. Start() on the other hand creates a new thread and then executes the run() method there. So the only special thing about run() is the name, in that start() knows about it.
I've noticed that the article doesn't show the call sequence for the caller of these two functions. It might be that the extra code from top2() simply gets generated in every function that calls top1(), and both of them end up with about the same overhead. I haven't tried to look at that code myself, so maybe top1() really is more efficient.

Note that top2() is really generated as 2 functions: the one starting at offset 19 is the contents of the synchronized() block and the one starting at offset 0 just sets up the synchronized block and then calls the inner function. That's what makes me think that the call of top1() would be wrapped by a similar set-up code.
It won't crash (thanks to the synchronized map) but it won't work right either. Think about what happens with the following sequence:

Thread A calls TimingMonitor.start("load file")
Thread B calls TimingMonitor.start("load file")
Thread A TimingMonitor.stop("load file")
Thread B calls TimingMonitor.stop("load file")

Both stop() calls will show the time since thread B called start().

I think Ragi is asking about the thread that called start(). There is no good reason to have this reference. There is no caller-callee relationship between threads. Not even a parent-child relationship like between the OS processed. One thread starts another and then may do whatever it pleases, including exiting. Having that reference would mean that if that thread exited, it could not be garbage collected until the other thread exits and gets garbage-collected too.

If you want, you can always add this manually by giving it as the argument to your thread constructor and remember it in the thread (subclass) object.
To keep the time synchronized, you need to run the NTP synchronization. On Unix that would be "ntpd", I'm not sure about Windows.
10 years ago