Hello,
On Thu, 17 Aug 2006, Arne Pajunen wrote:
Hello,
Attached is a patch of a fix I made to an issue we encountered with the
handling of the reader TLS (Thread Local Storage) keys in GIOPConn.
The issue was such that we had a call being made to a server, which returned
a reference to a generic resource. When the client receives this, Mico does a
_is_a query to verify it in the thread where the reply was received. In our
case this _is_a query went to another process with a different connection
which was just started by the server.
The problem was that the newly started connection created it's reader
threads, but then the query in the old connections reader thread calls
ORB:wait() to wait for the reply, and it determined that this is a reader
thread so it should directly call the dispatcher to wait for the reply.
Unfortunately, in this scenario it was the wrong reader thread, and the new
connections reader thread was also happily reading. This ended up with a race
in do_read(), where two threads would enter with the do_read simultaneously
causing a unpredictable condition.
Unfortunately I'm unable to produce a reasonable test case for it as this
occurred in a complex system, and was kind of rare and timing keen (sometimes
had to run the program in while loops until it occurred).
The exact issue is that the static MICO::GIOPConn::is_this_reader_thread()
method verifies whether current thread is a reader, but doesn't care for
which connection. I fixed this by making it use the pointer to the GIOPConn
instance as the thread local keys value, so it can verify that it's a reader
for the current connection.
I'm not sure if this patch is perfectly correct (or more like I'm not sure I
fixed the right problem.) and whether it has any side effects. I would be
interested in comments and feedback on this patch.
your information are very interesting. Could you also be so kind and tell
us what concurrency model do you use on client side? I would also be
interested to know more details about how is it possible you call _is_a
operation from reader thread directly. IMHO this shouldn't happen at
all...
Thanks,
Karel
--
Karel Gardas [EMAIL PROTECTED]
ObjectSecurity Ltd. http://www.objectsecurity.com
_______________________________________________
Mico-devel mailing list
[email protected]
http://www.mico.org/mailman/listinfo/mico-devel
