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

 
 

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

Submitted by:  Eric NOULARD <SyntDev1>
Submitted on:  Tue 28 Jan 2003 12:50:02 PM UTC  
 
Category: PackagingSeverity: 4 - Important
Status: PostponedPrivacy: Public
Assigned to: Eric NOULARD <erk>Open/Closed: Closed
Release: UnknownFixed Release: Unknown

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.
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>
Project 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>
Project 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>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 7 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 03 Jun 2006 09:13:09 PM UTCerkOpen/ClosedOpen=>Closed
  ReleaseNone=>Unknown
  Fixed ReleaseNone=>Unknown
Sun 18 Sep 2005 04:45:25 PM UTCerkStatusNone=>Postponed
Fri 18 Feb 2005 09:05:05 PM UTCerkAssigned toSyntDev1=>erk
Wed 04 Feb 2004 11:36:57 AM UTCdufySeverity3 - Normal=>4 - Important
Mon 03 Feb 2003 10:04:58 AM UTCtsp_adminAssigned toNone=>NA

Back to the top


Powered by Savane 3.1-cleanup1