Hi Eugene,

I just created  the branch.
I added you as a developer as well that way you can commit to
the branch.

Please be gentle with the commit access, Savannah does not
makes it possible to grant access to only 'part' of a repo.

So you have commit right "globally", I just ask you
to only commit in the branch.

Are you OK with that?

Hi Eric,

I've created independent libRTIA subdirectory, because in addition to both RTIA and libRTI multi-threaded LRC includes some extra sources. Thus, it results into some kind of new CERTI component and deserves the similar separation. However, I do not have any objections of moving it anywhere. As about the future prospective, I think it will be a nice catch to include multi-threaded LRC not only as a build, but as a run time option either. The internal RTIA-RTIG protocol is remains the same, so one execution can include both multi-process and multi-threaded LRCs. Thus, it seems quite reasonable to separate RTIA core into an independent library for convenient use in both cases.

>> "The polling I used is also an attempt to set aside the problem I know how to solve in favor of the those I do not"

Here I tried to express that I knew how to implement the considerably clean and correct solution in case of related waiting as well as I knew nothing about internal CERTI component communications. So I've made a kind of kludge to get the proof-of-concept multi-threaded LRC.

I understand your reluctance of including dependency on third-party library in CERTI. However, it seems quite strange to reject boost usage. Currently multi-threaded LRC version is considered as a build option, so the legacy configuration will not require boost at all. Although it is not too difficult to implement threading for one platform only, it will discriminate users of other platforms. If the user really wants to get multi-threaded LRC, he can easily get boost library for an appropriate platform. But there is no hope to do it in case of platform dependent code. Another option is to implement your own compile-time condition-based code for multiple platforms. Currently there are several lines of code in this patch, but the idea does not seem to be a fast fix already. Moreover, if you will try to use threads inside of RTIG in future, you likely require a mature full-featured threading library, and its development will be a crucial overhead for a small researcher group. To be honest, I do not think that it is a good idea to reject boost thread (or any of its competitors) even for now.

The development plan you suggested is quite reasonable. Thanks for your review and constructive criticism. I'm going to make the new branch as soon as I get enough time for it.

Hi Eric,

Thanks for your comments.

Built-in CERTI tests require some extra packages and I had troubles while building it on PC I did not have root. I agree this part do not correspond the threading topic at all. It is my fault this code leaked into proposal.

I agree the positive logic is easier to understand. I think the reason I wrote it negative is a custom to write include guard in C-headers.

I absolutely agree about the cmake include options. The center question for me in here is whether to add libRTI directory. If you think that it is an appropriate build solution, I am ready to modify the patch in a corresponding way.

The polling I used is also an attempt to set aside the problem I know how to solve in favor of the those I do not. In general I had to deal with the internal message protocol between RTIA and libRTI. The standard approach is to remove "select" and add the third thread to get usually more efficient related waiting as a result. If you have the similar feeling I can have a look on it either.

I am also consider the ring buffer to be a good approach, however currently it seems to be the second place task. In my opinion, we should made a working patch first. Thus the straightforward, clear and reliable boost mutex-guard implementation is the current best.

Looking for the following comments,
Eugene

Hi Eric,

Thank you for your fast and detailed reply.

Answering your first question, I have tested proposed patch on two tests. Each test federations consists of message [interaction] sender and registrar. Sender creates series of messages containing single numerical parameter. The initial positive value is set to parameter during the test initialization, and is decremented with each message send until it reaches zero value. During the first test the registrar just observes the passed parameter values. In case of the second test the registrar also replies to each message with its full copy,
and the sender does not send new messages until it gets the sender reply.
In fact, the second described test is a ping-pong test, I've submitted earlier: https://savannah.nongnu.org/patch/?7487.
I later learned, that despite the simplicity of these tests, they were used in some reserch papers and it has a consideration behind :-):
http://www.pitch.se/images//03s-siw-055.pdf [RTI-NGv6 Benchmarks].

Considering the benchmarking, for this purpose I have some python
scripts based on Dtest framework you adviced me before and give some automation. Actually comprehensive benchmarking of the proposed patch in comparison with the traditional CERTI architecture is currently my primary goal in this project.
I already have some unreliable preliminary results I can share:
Test No  WO Threads    Threads
1        4246 ms       1822 ms
2        8512 ms       4166 ms
This results I've got using a my laptop under 64 bit linux while 10 000 messages passed. These results seem to be rather prospective but now I'm not sure about the same dynamics
while using several computers - network communication may be the bottleneck here.

Considering your second question, primary target architecture is linux, but I am looking for a cross-platform solution in the first place.

This patch slightly changes CERTI RTI process model in attempt to increase overall RTI performance. Currently local RTI component consists of two full-weight processes, namely RTIA and Federate process. These processes interact to each other by means of TCP or UNIX socket (UNIX pipe). This type of interaction requires a lot of repeated message representation transitions and seems not to be an optimal one. There are a lot of suitable approaches: for example using of shared memory can partially solve the issue. The same common address space benefit could be reached by means of multi-threaded program.
Thus patch replaces two processes of local RTI component by the single two-threaded process.

Patch includes minor architectural changes only. It leaves unchanged the existing logical separation of duties between processes and uses the same message-based approach for local on host synchronization. Subsequently these mechanisms should be replaced due to its ineffectiveness, but all in good time.
For example, it seems prospective to make federate callbacks directly in context of the RTIA thread.

The next issue that deserves some consideration is a simultaneous polling of Federate and RTIG in RTIA thread.
Proposed patch cope with this using a handicraft combination of non-blocking 'select()' and thread polling. This approach is definitely not the best one and requires additional effort. Common pattern solution in this situation is to use an additional (the third) thread dedicated to socket listening. An interesting direction of researches here is the possibility of concurrent handling of both RTIG and federate messages.

Technically patch adds an option 'RTIA_USE_THREAD' that allows building of multi-threaded architecture whereas the traditional multi-process architecture is still available by default. Multi-threading is reached using cross-platform boost::thread library.

There are a lot of issues to be solved, and I will be glad to discuss the proposal, the possibility of its integration into the main CERTI development branch, and the prospective of the further development in the specified direction.