simultaneous function calls

[korcs]

Hi All,

I have not much experience with programming threads and competeing
processes.

I have an application, where several threaded-objects (each with an
own thread), are using the methods of a single (non-threaded) object.
I have no influence on the call frequency of theese threaded objects,
so it can easily happen, that 2 calls arrive at the same time, or a
call arrives when the object is still not returned from the previous
call.

I have experienced, that the application works the more erroneously
the more such "threaded instances" I have (with only one it works
perfectly, but I need in the final app around 15 of them!)

My question is: How java handles such calls. Is there some FCFS Queue,
so that each request is going to be satisfied sooner or later, or
there can be such requests, which can be forgotten?

Best,

korcs

 

[phi]

Hi All,

I have not much experience with programming threads and competeing
processes.

I have an application, where several threaded-objects (each with an
own thread), are using the methods of a single (non-threaded) object.
I have no influence on the call frequency of theese threaded objects,
so it can easily happen, that 2 calls arrive at the same time, or a
call arrives when the object is still not returned from the previous
call.

2 calls at the same time should not be a problem, if you synchronize the
method
using the "single (non-threaded) object" as monitor.
Simply add "synchronized" as keyword to the called method.

I have experienced, that the application works the more erroneously
the more such "threaded instances" I have (with only one it works
perfectly, but I need in the final app around 15 of them!)

This could be a synchronizing problem. But it's difficult to tell
without source code.

My question is: How java handles such calls. Is there some FCFS Queue,
so that each request is going to be satisfied sooner or later, or
there can be such requests, which can be forgotten?

"sooner or later". This is controlled by the operating system (so,
threads have not the same
scheduler on windows and linux for example.
To give the Threads a higher priority, use the threads "setPriority()"
method.

 

[Sabine Dinis Blochberger]

Hi All,

I have not much experience with programming threads and competeing
processes.

I have an application, where several threaded-objects (each with an
own thread), are using the methods of a single (non-threaded) object.
I have no influence on the call frequency of theese threaded objects,
so it can easily happen, that 2 calls arrive at the same time, or a
call arrives when the object is still not returned from the previous
call.

I have experienced, that the application works the more erroneously
the more such "threaded instances" I have (with only one it works
perfectly, but I need in the final app around 15 of them!)

My question is: How java handles such calls. Is there some FCFS Queue,
so that each request is going to be satisfied sooner or later, or
there can be such requests, which can be forgotten?

Best,

korcs

There's a very good lesson in Suns tutorial:
http://java.sun.com/docs/books/tutorial/essential/concurrency/

 

[Lew]

2 calls at the same time should not be a problem, if you synchronize the
method
using the "single (non-threaded) object" as monitor.

There is no such thing as a "non-threaded" object.

Since the object in question is used by many threads simultaneously, any
association with it of the term "non-threaded" is erroneous in this case.

The object must be written to be thread-safe.

This could be a synchronizing problem. But it's difficult to tell
without source code.

It's easy to tell without the source code: it's a synchronization problem.

To give the Threads a higher priority, use the threads "setPriority()"
method.

Not reliable, and not the answer to the OP's real problem.

Rule of thumb: At any given time, the highest priority thread is running. However, this is not guaranteed. The thread scheduler may choose to run a lower priority thread to avoid starvation. For this reason, use priority only to affect scheduling policy for efficiency purposes.
Do not rely on thread priority for algorithm correctness.

The tutorial that Sabine recommended is a necessary beginning. Study /Java
Concurrency in Practice/ by Brian Goetz, et al., for more mastery.

Thread programming is a subtle and dangerous art.

 

[Roedy Green]

My question is: How java handles such calls. Is there some FCFS Queue,
so that each request is going to be satisfied sooner or later, or
there can be such requests, which can be forgotten?

I implemented a simple thread system in C circa 1992. It kept a
control block for each thread. Each thread ran until it called
"haveAConscience". The thread manager stored its registers and stack
away for safekeeping. (Most of the stack was already in RAM). At that
point the thread manager picked the highest priority thread ready to
run, (which might be the same thread), restored its registers and
stack, and resumed it.

It was based on experience with the co-operating multitasker I had
used in the Univac 1616 military mini (for peaceful purposes as a
datacommunications front end to a mainframe) in the early 70s.

Java is more sophisticated. Threads don't have to call
"haveAConscience" periodically. There is a hardware timer in the OS
that goes off at the end of a slice. It can put a thread to bed in
the middle of evaluating an expression, or sometimes even in the
middle of an instruction.

Threads ask to be put to sleep when they do I/O and wake up, getting
on the active queue when the I/O completes.

The OS, not Java handles most of this. A Thread in Java is the set of
machine registers, and the contents of a stack (locals, return values
to callers, parameters).

My current machine has two CPU cores, so it can run two threads fully
simultaneously. Cheaper hyperthreaded machines simulate dual or more
CPU cores, so the threads interleave on a cycle by cycle bases, rather
than timeslice by timeslice.

see http://mindprod.com/jgloss/thread.html

 

[korcs]

Thanks for your replies!

I found myself a really good tutorial for java threads as well.

http://www.freejavaguide.com/java-threads-tutorial.pdf

While reading your comments and the suggested tutorials, I was
wondering whether my problem was really a synchronization problem.

Maybe I did not understand everything quite well, but it seems to me,
that synchronization is needed in situations where 2 or more threads
could WRITE(!) global variables simultaneously and make data
inconsistent.

So it means that if a method, used maybe simultaneously by multiple
threads causes only a READ action on program data, then
synchronization is not necessary (not needed and would cause only an
unneccesary overhead).

Is it correct or did I miss something?

Best,

korcs

 

[Sabine Dinis Blochberger]

Maybe I did not understand everything quite well, but it seems to me,
that synchronization is needed in situations where 2 or more threads
could WRITE(!) global variables simultaneously and make data
inconsistent.

So it means that if a method, used maybe simultaneously by multiple
threads causes only a READ action on program data, then
synchronization is not necessary (not needed and would cause only an
unneccesary overhead).

Not really. Imagine your method is traversing a file. Then every call to
it moves the file pointer, and gives you unexpected results.

Maybe you could describe your *specific* situation better, with some
code, then people could find the culprit.

 

[Lew]

Thanks for your replies!

I found myself a really good tutorial for java threads as well.

http://www.freejavaguide.com/java-threads-tutorial.pdf

While reading your comments and the suggested tutorials, I was
wondering whether my problem was really a synchronization problem.

Maybe I did not understand everything quite well, but it seems to me,
that synchronization is needed in situations where 2 or more threads
could WRITE(!) global variables simultaneously and make data
inconsistent.

So it means that if a method, used maybe simultaneously by multiple
threads causes only a READ action on program data, then
synchronization is not necessary (not needed and would cause only an
unneccesary overhead).

False if the datum in question is non-immutable and non-final.

Is it correct or did I miss something?

You missed something.

If more than one thread /accesses/ a variable, read or write, you must
synchronize. The "synchronized" keyword is not the only way to synchronize.

Compile-time constants and static final immutable objects are synchronized by
the rules of when such things are created. Thus read-only access can avoid
"synchronized" in such cases, but it doesn't avoid synchronization.