Just wanted to disengage the discussion of locking issues from Balloon and other special components. In my previous post on one of the threads I remarked that each user component has the opportunity to inspect and change FBP internal data. The reason is, that a user component extends the fbp.engine.Component. This creates access to all protected items in Component. Thus FBP internal state.
Many of the items that we define protected in Component need to be protected, because other objects within the engine need access to these items.
The problem with this is that it is engine-internal state and the user component should not be able to touch it. I am not sure that in your book you formulated it that way, but I am pretty confident that you meant components to be independent of the operating software, the software that manages and schedules components.
The only conclusion that I can think of is that the user component is too closely integrated into the engine.
The questions are:
Do you agree?
How could we tear the user components away from the engine without disrupting user software?
Should we develop internal components that can reach the internal state? Or should these be like the user components?
Although I can not answer question 1, and we should both think about question 3, I do have an idea of the answer to question 2.
We could lift the coding of Component into a different class and have the remaining Component interface with the engine. That would effectively de-couple the user components from the engine, without disrupting function.
The user would lose access to internal state. The FBP engine would gain reliability and ease of maintenance, because internally we no longer have to reckon with external forces that could disrupt the engine (and blame us for improper publishing).
What do you think? And please be blunt or at least Frank (I keep wondering why you bring up Sinatra all the time? :) ).
Actually, I agree with you - given what I have learned about protected, what you say makes sense. I actually did something like what you describe in my CppFBP implementation (actually, its ancestor, THREADS) - this was because, in THREADS, you could load a DLL and it didn't have access to any public fields - well, hardly any. So, I ran all the API calls through a narrow "neck" which also identified the process involved. I will take a look and see if I can reconstruct something (maybe even similar) for JavaFBP. I think you are quite right, the core isn't well protected from rogue processes!
This implies to me a few things:
a) if we are going to do this, I don't see much point in all this annotating and changing variable modifiers that you are doing - the only things which will be visible to a process will be the APIs, Network, Component (which John should have called Process!) and the port classes
b) the work you are about to start, looking at ReentrantLocks and Conditions, remains very important - if not more so
c) we can't change the names of the public classes: Network, Component, InputPort, OutputPort, Packet, and the annotation classes, as we don't know who out there is using them - but we can "split" them, and we can and should change everything else!
d) the work on user vs. engine shouldn't be in 2.7 - we should create a whole 'nother branch...
I will start some investigations, and touch base with you on this when I have some options to present...
Actually, I never listened to Frankie much - I was and am more into Latin...
Annotation is documentation about concurrency for the future maintainers (which may be ourselves or someone else). They are only necessary where multi threading is concerned. I expect they will never leave the engine as the engine will always have some sharing across threads. Time will tell.
Granted, working on reentrant locks and Conditions. Will get back to you when I actually have something to say about it.
Agree, names should stay the same. They will be like a protective shield around the engine. They are the API between the engine and the user components.
And they will show no internal state.
Agree. I even thought we could do the experiment in a copy of JavaFBP, and call it something else for the time being (tiger seems to be a popular name :) ). That way in time we could chose whether to be completely backward compatible or not.
Me, I used to be a Simon and Garfunkel fan, and I still am, but classical music has really won me over. Still, we don't have enough people like Paul Simon on this world!
Kind regards, Guus.
P.S. The annotations are not for users, but for engine maintainers : hope that much was clear.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.