Re: linux
Masnizar jamian wrote: I'm new to linux , so are there any difference between windows platform and linux in terms of coding (mainly in multithread)? Because I heard that a linux thread is different from windows thread. Could you recommend me any reading material that clear some cobweb in my brain ? Thanks in advance for helping me. As far as Java is concerned, there is no difference in the software API. Now, when you get to the C/C++ level, things change rather significantly due to the fact that Linux is Unix-like/Posix and Windows is, well, it is Win32. However, Java "hides" all of that and provides a very nice, language defined threading model with all of the tools needed to build complex multi-threaded applications that run on any JVM of the same release level. (JDK 1.2 is JDK 1.2 anywhere, for example) -- Michael SinzTechnology and Engineering Director/Consultant "Starting Startups" mailto:[EMAIL PROTECTED] My place on the web http://www.sinz.org/Michael.Sinz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Green vs Native Threads
Folks, what's the diference between Native and Green Threads for the performance of a software and for System Operation? The new Linux Kernel 2.4.20 manage all threads as Native, but using the concept of Green? Regards, Henrique -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Masnizar jamian wrote: I'm new to linux , so are there any difference between windows platform and linux in terms of coding (mainly in multithread)? The only difference I know of (after coding for both platforms for about five years) is that if you are using popup menus, the trigger is a mouse press in Unix and a mouse release in W** (meaning you have to check for both events to see if MouseEvent.isPopupTrigger() returns true). -- Glenn Holmer [EMAIL PROTECTED] Programmer/Analyst phone: 414.908.1809 Weyco Group, Inc. fax: 414.908.1601 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Green vs Native Threads
On Thu, 2003-02-06 at 04:41, Henrique wrote: > Folks, what's the diference between Native and Green Threads for the > performance of a software and for System Operation? Green Threads is linked into the JDK to simulate a threading environment; it manages all thread creation, scheduling, communication, etc. There have been many other similar threads packages written over the years, used by apps that need multi-threading but need to run on operating systems that either don't support threads, or do it inadequately for the application. Native threads is just that, the JDK uses the threading support in the underlying operating system. The advantage of a threading package like green is that the app has identical behavior on systems with different or nonexistent threading support (plus, you can fix bugs in it!). The disadvantage is a big one, however: the app can only run in a single OS thread. This means that the app cannot benefit from OS support for things like multiple processors. Another disadvantage is that application behavior may be slightly different than native apps. On a single processor system, performance should be very similar and in some cases green may actually be slightly faster because it is lighterweight than some OS threading systems. If you have multiple processors (or your customers do), then native is the only way to go. As a developer, one should rarely worry about which threads package is running -- just use the default. The exception is that some debugging and profiling tools may not fully work with native threads, in which case use green if it's available and recommended by the tools vendor. > The new Linux Kernel 2.4.20 manage all threads as Native, but using the > concept of Green? Green vs. native threading is a Java Virtual Machine option, not a kernel one. They may share some concepts (all threading systems do), but their implementations are completely different. Tom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Glenn Holmer wrote: Masnizar jamian wrote: I'm new to linux , so are there any difference between windows platform and linux in terms of coding (mainly in multithread)? The only difference I know of (after coding for both platforms for about five years) is that if you are using popup menus, the trigger is a mouse press in Unix and a mouse release in W** (meaning you have to check for both events to see if MouseEvent.isPopupTrigger() returns true). Uggg... I forgot about that one - I have a class that takes care of that stuff and, well, it handles all cases. (BTW - that is not the only case of slight difference between up-event and down-event handling between various platforms) -- Michael SinzTechnology and Engineering Director/Consultant "Starting Startups" mailto:[EMAIL PROTECTED] My place on the web http://www.sinz.org/Michael.Sinz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Masnizar jamian wrote: I'm new to linux , so are there any difference between windows platform and linux in terms of coding (mainly in multithread)? Because I heard that a linux thread is different from windows thread. Could you recommend me any reading material that clear some cobweb in my brain ? Thanks in advance for helping me. Thread priorities don't work in Linux, and neither does Thread.yield() (couldn't it be implimented as sleep(1)?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
On Thu, Feb 06, 2003 at 06:11:03PM -0500, Joseph Shraibman wrote: > Masnizar jamian wrote: > > > >I'm new to linux , so are there any difference between windows platform > >and linux in terms of coding (mainly in multithread)? Because I heard > >that a linux thread is different from windows thread. Could you > >recommend me any reading material that clear some cobweb in my brain ? > >Thanks in advance for helping me. > > > Thread priorities don't work in Linux, and neither does Thread.yield() > (couldn't it be implimented as sleep(1)?) Thread.yield() works fine - it seems to me that Juergen did a good job of addressing that issue in the 2/2001 discussion Joseph started: http://groups.yahoo.com/group/java-linux/message/15646 Nathan Meyers [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
JMStudio can't transmit
hi, i have a problem where each JMStudio on two separate computers linked through a LAN can't communicate. tcpdump shows nothing when i start transmitting audio. i got lots of failed transmission in Transmit statistics. Why does this happen since all my LAN setting are right? Even "ping" works. Please help. I need to resolve this problem in few days time. Thanks a lot! =] Regards, Chin _ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
On Thu, 2003-02-06 at 20:18, Nelson Minar wrote: > >Alexander V. Konstantinou wrote: > >> Actually, thread priorities work fine in Linux. > >No, they don't, not with the latest sun jdk on redhat 8.0. > > Is it green threads or native threads that don't work? > > btw, the JVM spec on what thread priorities mean is very very loose. > If I remember correctly, a JVM could ignore the priorities entirely > and still be technically "correct". That's why normal business applications *never* mess around with thread priorities. However, the capability of spawning threads is enough to solve a lot of problems. -- Weiqi Gao [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to Make JVM work faster
Hi All We are in a process of making a routing selector , am just curious what advantage the JAVA can have over C++ ( apart from multiplatform) in processing the request faster...??? Is there any article that i can read to understand how to make the process fast or how we can tweak around with JVM or BYTE code for the same Thanks and regards -Shishir WARNING: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
I'm attaching the ThreadTest file which I forgot to include in
my benchmark message.
Alexander
public class ThreadTest extends Thread {
public static final long MAX_COUNT = 10;
public final char id;
public long counter = 0;
public ThreadTest peer = null;
public boolean isYield = false;
public boolean isNoop = false;
public ThreadTest(char id) {
super("Thread" + id);
this.id = id;
}
public void noop() {
}
public void setYield(boolean isYield) {
this.isYield = isYield;
}
public void setNoop(boolean isNoop) {
this.isNoop = isNoop;
}
public void setPeer(ThreadTest peer) {
this.peer = peer;
}
public void run() {
long startTime = System.currentTimeMillis();
while(counter < MAX_COUNT) {
if ( (isYield) && (counter % 1000 == 0) ) {
yield();
} else if ( (isNoop) && (counter % 1000 == 0) ) {
noop();
}
counter++;
}
System.out.print("Thread" + id + " " +
(System.currentTimeMillis() - startTime) + " ms");
if (peer != null) {
int percent = (int) double) peer.counter) / MAX_COUNT) * 100);
System.out.print(" [peer counter=" + peer.counter + " (" +
percent + "%) ]");
}
System.out.println(" isYield=" + isYield + " isNoop=" + isNoop);
}
/**
* Usage:
*
* java ThreadTest
* java ThreadTest thread1
* java ThreadTest thread1 yield
* java ThreadTest thread2
* java ThreadTest thread2 yield
*/
public static void main(String[] args) {
ThreadTest thread1 = new ThreadTest('1');
ThreadTest thread2 = new ThreadTest('2');
thread1.setPeer(thread2);
thread2.setPeer(thread1);
boolean isYield = false;
boolean isNoop = false;
if (args.length > 1) {
if (args[1].equals("yield")) {
isYield = true;
} else if (args[1].equals("noop")) {
isNoop = true;
} else {
System.err.println("Unknown argument '" + args[1] + "'");
System.exit(1);
}
}
if (args.length == 0) {
// Same priority as main thread
} else if (args[0].equals("thread1")) {
thread2.setPriority(Thread.MIN_PRIORITY);
thread1.setYield(isYield);
thread1.setNoop(isNoop);
} else if (args[0].equals("thread2")) {
thread1.setPriority(Thread.MIN_PRIORITY);
thread2.setYield(isYield);
thread2.setNoop(isNoop);
} else {
System.err.println("Unknown argument '" + args[0] + "'");
System.exit(1);
}
thread1.start();
thread2.start();
}
}
Re: linux
Joseph Shraibman wrote: Thread.yield() is used under two different scenarios: + waiting for certain condition to become true (or false), most likely this is used in a yield loop, and current thread has nothing to do but burning CPU cycles in a while loop. + be nice and let kernel/pthread know that this would be a good point to schedule another thread to run, current thread still has some work to do. Such yields are necessary for non-preemptive schedulers (e.g. green thread). In the first case, it's probably OK to sleep(1), but it makes no sense for the second case. Uh, sure, forcing yourself to sleep means another thread will be scheduled. They don't really want to be kicked out of CPU. But you have to have those yield()'s inserted into a program because otherwise the program would not work with, say, green threads. For example, you need to place yields in computational loops to voluntarily give up execution so it won't occupy all CPU cycles and block other threads. The yields are convenient points for scheduler to kick in, but the thread has useful stuffs to do if it's kept in CPU a little longer. When the same program is running with native threads, it's more efficient if such yields are considered as nops, since context switchings are expensive and scheduler is now able to switch threads at any point. Sleep(1) is even worse in this case because it leaves CPU idle when it can do useful work. (did I mention sleep(1) can actually take 10ms, because of clock granularity?) That being said, by default Sun's JDK converts Thread.yield() directly to sched_yield() on Linux. Kernel scheduler will decide whether or not to actually switch context. -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Actually, thread priorities work fine in Linux. The main difference has to do with threads of the SAME priority level. In Windows, Java performs time-slicing, that is, threads of the same priority share the CPU by taking turns. In Linux, that is not the case. A thread that does not relinquish control by blocking (e.g. an endless while loop), will not only starve lower priority threads, but also threads with the same priority. Therefore, make sure that you either assign different priority levels, or that busy threads take the time to invoke Thread.yield() from time to time. Alexander On Thu, Feb 06, 2003 at 06:11:03PM -0500, Joseph Shraibman wrote: > Masnizar jamian wrote: > > > > I'm new to linux , so are there any difference between windows platform > > and linux in terms of coding (mainly in multithread)? Because I heard > > that a linux thread is different from windows thread. Could you > > recommend me any reading material that clear some cobweb in my brain ? > > Thanks in advance for helping me. > > > Thread priorities don't work in Linux, and neither does Thread.yield() (couldn't it >be > implimented as sleep(1)?) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Alexander V. Konstantinou wrote: Actually, thread priorities work fine in Linux. No, they don't, not with the latest sun jdk on redhat 8.0. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
From: "Alexander V. Konstantinou" <[EMAIL PROTECTED]> > The main difference has > to do with threads of the SAME priority level. In Windows, Java performs > time-slicing, that is, threads of the same priority share the CPU by > taking turns. In Linux, that is not the case. A thread that does not > relinquish control by blocking (e.g. an endless while loop), This is correct only for Green Threads, which is a user-space threading library for the Classic VM. Few people use Green Threads in the recent days. Additionally, even old java commands using Green Threads provided -tss option. When the option is given, threads are scheduled in a time-slicing fashion. I guess even user-space threads can implement time-slicing with kinds of signal and alarm(2). But, I'm not sure the -tss option could work well ever on Linux. Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Joseph Shraibman wrote: Alexander V. Konstantinou wrote: Actually, thread priorities work fine in Linux. No, they don't, not with the latest sun jdk on redhat 8.0. Thread priority is just a hint (same applies to Thread.yield()). It's up to the underlying system (in this case, the Linux kernel scheduler) to decide whether or not to honor thread priorities. On Linux, threads are cloned processes and are scheduled in the kernel space. JDK passes the priority information to the kernel, but they are ignored. It may sound like a surprise, but most of the time kernel scheduler can do a better job than human in prioritizing jobs. After all, only kernel scheduler knows how threads interact with each other and/or with other applications. -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
>Alexander V. Konstantinou wrote: >> Actually, thread priorities work fine in Linux. >No, they don't, not with the latest sun jdk on redhat 8.0. Is it green threads or native threads that don't work? btw, the JVM spec on what thread priorities mean is very very loose. If I remember correctly, a JVM could ignore the priorities entirely and still be technically "correct". [EMAIL PROTECTED] . . . .. . . . http://www.media.mit.edu/~nelson/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Hui Huang wrote: Joseph Shraibman wrote: Alexander V. Konstantinou wrote: Actually, thread priorities work fine in Linux. No, they don't, not with the latest sun jdk on redhat 8.0. Thread priority is just a hint (same applies to Thread.yield()). While the jvm authors can't do anything about the kernel ignoring the priority, they *can* do something about Thread.yield(): make it the equivalent to sleep(1) kernel space. JDK passes the priority information to the kernel, How? but they are ignored. It may sound like a surprise, but most of the time kernel scheduler can do a better job than human in prioritizing jobs. Um, no. The few cases I would set a priority I would have a good reason. BTW does the jvm give threads with higher prio prefrence when delivering notify()'s? -- Joseph Shraibman [EMAIL PROTECTED] Increase signal to noise ratio. http://xis.xtenit.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Joseph Shraibman wrote: Hui Huang wrote: Joseph Shraibman wrote: Alexander V. Konstantinou wrote: Actually, thread priorities work fine in Linux. No, they don't, not with the latest sun jdk on redhat 8.0. Thread priority is just a hint (same applies to Thread.yield()). While the jvm authors can't do anything about the kernel ignoring the priority, they *can* do something about Thread.yield(): make it the equivalent to sleep(1) No. sleep(0) would come close, not sleep(1). Thread.yield() is used under two different scenarios: + waiting for certain condition to become true (or false), most likely this is used in a yield loop, and current thread has nothing to do but burning CPU cycles in a while loop. + be nice and let kernel/pthread know that this would be a good point to schedule another thread to run, current thread still has some work to do. Such yields are necessary for non-preemptive schedulers (e.g. green thread). In the first case, it's probably OK to sleep(1), but it makes no sense for the second case. And you can always sleep on a monitor instead in the first case, it's better than yield. sleep(0) is acceptable for both cases, but again with sleep(0), it's up to the scheduler to decide if or not to actually switch context. kernel space. JDK passes the priority information to the kernel, How? pthread_setschedparam. Note that sched_priority is ignored under SCHED_OTHER policy. but they are ignored. It may sound like a surprise, but most of the time kernel scheduler can do a better job than human in prioritizing jobs. Um, no. The few cases I would set a priority I would have a good reason. BTW does the jvm give threads with higher prio prefrence when delivering notify()'s? No, IIRC. -hui -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux
Hui Huang wrote: Joseph Shraibman wrote: Hui Huang wrote: Joseph Shraibman wrote: Alexander V. Konstantinou wrote: Actually, thread priorities work fine in Linux. No, they don't, not with the latest sun jdk on redhat 8.0. Thread priority is just a hint (same applies to Thread.yield()). While the jvm authors can't do anything about the kernel ignoring the priority, they *can* do something about Thread.yield(): make it the equivalent to sleep(1) No. sleep(0) would come close, not sleep(1). Except I looked at the code and sleep(0) doesn't do anything. At least when I looked. Thread.yield() is used under two different scenarios: + waiting for certain condition to become true (or false), most likely this is used in a yield loop, and current thread has nothing to do but burning CPU cycles in a while loop. + be nice and let kernel/pthread know that this would be a good point to schedule another thread to run, current thread still has some work to do. Such yields are necessary for non-preemptive schedulers (e.g. green thread). In the first case, it's probably OK to sleep(1), but it makes no sense for the second case. Uh, sure, forcing yourself to sleep means another thread will be scheduled. And you can always sleep on a monitor instead in the first case, Unless you are a lazy coder ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
