Weblogs Forum - Threading Terminology

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Threading Terminology

23 replies on 2 pages. Most recent reply: Oct 4, 2005 10:40 AM by Jonathan Dodds

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]

Sebastian Kübeck

Posts: 44
Nickname: sebastiank
Registered: Sep, 2005

Re: Threading Terminology

Posted: Oct 2, 2005 10:39 AM

Thx alot for the book recommendations.
Now I don't have to waste money on the
wrong books anymore ;-).

Peter is right with the Holub book.
It's more confusing than helpful
especially because there's way too little
emphasis on explaining the basics.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Threading Terminology

Posted: Oct 2, 2005 10:57 PM

> > Maybe real question is : what is the difference between
> > a "process" and a "thread" ?
>
> A process has its own memory space. It's usually done at
> the operating system level...
> ... I would suggest that one reason that Java uses
> threads and not processes is because the original Mac OS
> was not multitasking...

I thought the reason was that the JVM itself is just a process running on a machine (which itself could be real or virtual). In this context, it makes sense that the JVM can only deal with threads. (yes, yes, it can exec() a process, but then that process becomes essentially unknown to the JVM).

I thought that was also the reason Java doesn't have mutexes and semaphors, etc. After all, there may be any number of JVMs running on a single machine and none of them know about the others, or any other process for that matter. That is all just part of running in a virtual machine, isn't it?

As for the complexity of threading in Java, I thought it was pretty darned clean and simple compared to the raw C/C++ stuff. Maybe that was because I had already had a few years of exposure to it before I saw it in Java, whereas C/C++ was my first exposure. ...no, I still think threading in C/C++ is crude compared to Java or C#.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Threading Terminology

Posted: Oct 3, 2005 6:27 AM

> I thought that was also the reason Java doesn't have
> mutexes and semaphors, etc.

J2SE5 has semaphores.

And mutexes, unless you're talking about something other than

synchronized(ob) {
// mutex region
}

> As for the complexity of threading in Java, I thought it
> was pretty darned clean and simple compared to the raw
> C/C++ stuff. Maybe that was because I had already had a
> few years of exposure to it before I saw it in Java,
> whereas C/C++ was my first exposure. ...no, I still think
> threading in C/C++ is crude compared to Java or C#.

Java's threading is an improvment over C/C++ pthreads; it cleans up the rough edges, but it still uses the basic model of pthreads. That approach is very low-level, and doesn't allow for much in the way of automatic verification, and doesn't scale. Also, it's a trap for novices.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Threading Terminology

Posted: Oct 3, 2005 8:46 AM

> > I thought that was also the reason Java doesn't have
> > mutexes and semaphors, etc.
>
> J2SE5 has semaphores.

Okay, then maybe those can be mutated into mutexes.

> And mutexes, unless you're talking about something other
> than
>
> synchronized(ob) {
> // mutex region
> }

No, my understanding of mutexes (which may be wrong, but that goes back to the title of this discussion) is that they are on the OS level. Mutexes should work between processes, not just threads, so they are at a higher level. (I thought the example you gave above was called a "lock").

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Threading Terminology

Posted: Oct 3, 2005 9:02 AM

Mutex is short for "mutual exclusion." It is a device that prevents more than one -- let's call it a "task" to be generic -- task at a time from accessing or modifying a shared resource.

So, if you're using a process, as you are referring to, that's generally managed at the OS level, and thus you need an OS-level mutex mechanism to prevent process-level tasks from interfering with each other.

And if you're working with threads, you need a thread-level mutex mechanism to prevent thread-level tasks from interfering with each other. In J2SE5, this includes the built-in locks that are part of every object and that you get with the synchronized keyword (that is, the original locks), and also the new java.util.concurrent.locks.Lock objects. (Locks are also called monitors).

Semaphores (also a new utility class in java.util.concurrent) allow you to keep a count of threads that have entered a particular critical section. Semaphores are generally used to create mutexes, not the other way around (the built-in lock in Java keeps track of how many acquisitions that a particular thread has acquired on a particular lock, and only releases the lock when the count goes to zero, so internally it looks like a semaphore).

Jonathan Dodds

Posts: 464
Nickname: jrdodds
Registered: Mar, 2004

Re: Threading Terminology

Posted: Oct 3, 2005 9:19 AM

> No, my understanding of mutexes (which may be wrong, but
> that goes back to the title of this discussion) is that
> they are on the OS level. Mutexes should work between
> processes, not just threads, so they are at a higher
> level. (I thought the example you gave above was called
> a "lock").

I have always understood a mutex to be just a type of lock. The idea that a mutex by definition must be visible across processes is news to me and I believe most 'mutex' implementations fail that definition.

MS Windows implements kernel level mutexes that are visible across processes. As another example of the confusion around threading, I have noticed Windows specific material that doesn't make a distinction between the generic concept of a mutex and the concrete Windows implementation of mutexes.

(OT: There's a lot of propaganda and convenient omissions in the MSDN. It's important to be a critical reader.)

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: Threading Terminology

Posted: Oct 3, 2005 10:34 AM

I read this post and the replies and felt compelled to update my blog for the first time in months. Briefly, can a language or platform ever conquer threads? Should we consider multi-processes vs. mult-threads?
thanks
http://mikepetry.blogspot.com/2005/10/bruce-on-threading-terminology.html

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: Threading Terminology

Posted: Oct 3, 2005 11:03 AM

I can speak to win32 threading. A Mutex is indeed a multi-process object and can be used to synchronize across processes. The win32 Mutex must be uniquely 'named' so that it may be discovered by other processes and threads. The win32 Mutex may also be set with Security Attributes which is essentially a Access Control List.
The mutex is a very primitive low-level means of synchronizing processes but is far better than nothing at all.
Problems arise when a system consists of multiple processes, one of which is a Java process, and synchronization must occur.
If all processes in the system are required to use a named mutex, how does the Java app participate?
Java is known for its mult-threading ability. Therefore the system may be designed so that all the multi-threading occurs in the Java app. How are the other applications going to synchronize with the Java threads? I am utilizing a framework with this problem.
None of these problems are insurmountable, I hope, but are far beyond the scope of typical Java application development.
Also, I think Java 1.5 has a method in java.lang.system that exports the JVM main thread.
Other problems may occur in terms of security. Java is its own 'platform' and mananges succurity apart from win32, how does one rectify differences in security models?

Jonathan Dodds

Posts: 464
Nickname: jrdodds
Registered: Mar, 2004

Re: Threading Terminology

Posted: Oct 4, 2005 10:40 AM

Java is its own platform and part of that platform's purpose is to provide portability. Although Java threads are mapped to actual Win32 threads by the Windows JVM, Windows specific features like named mutexes and Windows security attributes are not exposed in Java.

If lack of portability is not an issue, you can use the JNI (Java Native Interface) to call 'native' code from Java and to allow 'native' code to call into your Java code.

Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic