bugTransport Sample Protocol - Bugs: bug #2412, GLU server (stage1) thread and...

 
 

bug #2412: GLU server (stage1) thread and datapool thread coordination trouble

Submitter:  Eric NOULARD <SyntDev1>
Submitted:  Tue 28 Jan 2003 12:50:02 PM UTC
   
 
Category:  Packaging Severity:  4 - Important
Status:  Postponed Privacy:  Public
Assigned to:  erk Open/Closed:  Closed
Release:  * Unknown Fixed Release:  * Unknown
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 03 Jun 2006 09:13:09 PM UTC, comment #6: 

This problem has disappeared since we start
the GLU thread immediatly after TSP_provider_run (ACTIVE GLU)
[or upon request sample init (PASSIVE GLU)]
and we do not have any ringbuf between GLU and TSP Core.
 
I close it.

Eric NOULARD <erk>
Group administrator
Sun 18 Sep 2005 04:45:25 PM UTC, comment #5: 

I postponed this issue since the refactoring step
may simply make this issue disappear.

Eric NOULARD <erk>
Group administrator
Wed 04 Feb 2004 11:36:32 AM UTC, comment #4: 

The bug is more vicious than that. It also appears if you wait a long time (more then 10s) between the connection and the start of the sampling. And the stub stay frozen, even if you start again a new client.
I like the solution of creating the GLUE thread in the get_next_item. It let the GLUE stupid and use nore more mutex than necessary.
But I wonder if we shouldn't forget the "thread creation" on the provider side, and just offer a library for creation the TSP serveur, and let the provider build himself the glue side, because the approch can be very different (VxWorks, Simix, main unix, ....)
Any ideas ?
Y++

Yves Duf <dufy>
Group Member
Wed 04 Feb 2004 11:26:33 AM UTC, comment #3: 

Thanks for helping us tracking bugs in TSP. Be sure you send all
the log & context on the problem.
Please be sure will do our best for correcting it.

Regards,
TSP admin

TSP administrator <tsp_admin>
Group administrator
Thu 30 Jan 2003 10:37:52 AM UTC, comment #2: 

We should think of a design by contract approach between
GLU and the provider.
(http://www.elj.com/eiffel/dbc/)
Each GLU API which should be coded by the GLU writer
must fullfill a contract. We certainly may not be able
to check it automagically. But it should refrain the GLU
writer from writing "almost anything".

For DBC here, I does mean pre/post condition but
dynamicall issues.

For example, the GLU_thread should be
silently tolerant to the full ringbuf issue
till the first get_next_item comes out
(which is the sign of clear datapool thread activity).
The GLU thread may well not put ANYTHING in the ringbuf
until a first call to get_next_item is done.

The GLU may maintain a 'GLU state' accessible from
GLU_state() API and we may have a Provider_state()
API which may be used both by the GLU and provider
API to handle dynamical issue.


We should ideally be able to give a contract
description for each GLU API.
The contract should describes:
  - pre/post conditions of  the API
  - dynamical issue (when,after/before which)
    API to be call.

Eric NOULARD <SyntDev1>
Tue 28 Jan 2003 11:19:25 PM UTC, comment #1: 

Hum...The tricky point here is that we'd better not
share some sort of mutex between the GLU code and
the TSP code (given that everybody can write anything
on the GLU part (and 'anything' is the good word for the GLU code of tests/stage1, I grant you that :)) . )

Well...I don't know...maybe the datapool thread should call
some function in the GLU itself so as to be sure that it
is alive...(ex : GLU_start_send_data) a function where
we could start the thread in the GLU ( and we do not
start this thread in GLU_get_instance)...

Or, easier, but uglier, the GLU thread could be created
during the very first GLU_get_next_item...

Suggestions ?




Stephane GALLES <sgalles>
Group Member
Tue 28 Jan 2003 12:50:02 PM UTC, original submission:  


Using a forthcoming very nice Java consumer :))
The tsp server of the tests/stage1 example has
2 bugs:

1) first the RINGBUF size between GLUE_thread
   and Datapool thread is too small (3 second)
   since datapool thread start after GLUE thread
   the GLUE thread may totally fill the RINGBUF
   BEFORE the first get_next_item is called by
   the datapool thread.
   There should be a coordination mecanism between
   RINGBUF producer and RINGBUF consumer at startup.

2) As soon as the GLU failed to put an item in
   the RINGBUF it is impossible to get out of
   this state since data_missed is NEVER set back
   to false :=)


I think that since my tests are done on a unique
machine the Java consumer start-up may well delay the
datapool thread startup more than the very nice
C client of the test.

Pushing the ringbuf size from 3 seconds to 10
solves the problem. Which is definitely NOT a solution
for a multimilloin symbols glu server:))

Eric NOULARD <SyntDev1>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

Follow 7 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2006-06-03 erk Open/ClosedOpen Closed
    ReleaseNone Unknown
    Fixed ReleaseNone Unknown
2005-09-18 erk StatusNone Postponed
2005-02-18 erk Assigned toSyntDev1 erk
2004-02-04 dufy Severity3 - Normal 4 - Important
2003-02-03 tsp_admin Assigned toNone None

Back to the top

Powered by Savane 3.13-caa5.
Corresponding source code