架构设计 [英] Architecture design

问题描述

大家好。我正在编写程序的文档我将要开发（是的，在实现之前的文档，它很棒！）。


简而言之，它将在Linux作为操作系统的Linux平台上运行。我有一些硬件设备必须向网络上的

服务器发送数据并从中接收数据。我将使用一个TCP流进行所有通信。


基本上我打算做的是以下内容：

- 程序模块化为可能，它将在

目录中查找plugins用共享对象实现。每个插件

都会声明什么是类型它将发送或接收的数据。

- A主要线程将启动每个插件作为一个单独的线程。

- 每个插件线程将管理硬件;它最终将会有什么东西发送到服务器而反之亦然


实现这种数据交换的最佳方法是什么？我不想在主线程的插件中找到执行代码的
执行代码。因为一个写得不好的
编写的插件可能会阻塞太多时间（或无限期）其余插件和数据传输的

操作。


我的想法是让主线程或插件线程在线程安全队列中插入

数据，然后向收件人发送信号
（主要或插件取决于数据流）通知它必须处理

数据。


你怎么看？ br />
Alessio

Hi all. I am writing the documentation for the program I''m going to
develop (yes, documentation before the implementation, it''s awesome!).

In short, it will run on an embedded platform wint Linux as OS. I have
some hardware devices that have to send data to and receive data from a
server on the network. I will use one TCP stream for all the communication.

Basically what I plan to do is the following:
- for the program to be as modular as possible, it will look in a
directory for "plugins" implemented with shared objects. Every plugin
will declare what "type" or data it will send or receive.
- A "main" thread will start each "plugin" as a separate thread.
- Every "plugin-thread" will manage the hardware; it will eventually
have something to send to the server and viceversa

What is the best way to implement this data exchange? I''d prefer not to
execute code found in the plugin from the "main-thread" because a poorly
written plugin may block for too much time (or indefinitely) the
operations of the rest of the plugins and the data transfer.

An idea I had was to have the main-thread or the plugin-threads insert
data in a thread-safe queue, and then send a signal to the recipient
(main or plugin depending on the data flow) to inform it has to process
the data.

What do you think?
Alessio

推荐答案

Alessio Sangalli< al **************** **@manoweb.com写：

< snip>

Alessio Sangalli <al******************@manoweb.comwrites:
<snip>

简而言之，它将在Linux作为操作系统的嵌入式平台上运行。

In short, it will run on an embedded platform wint Linux as OS.

comp.unix.programmer可能是讨论整体

设计的合理位置。


< snip>

comp.unix.programmer is probably a reasonable place to get the overall
design discussed.

<snip>

我的想法是让主线程或插件线程在线程安全队列中插入
数据，并且然后向收件人发送一个信号

（主要或插件取决于数据流），告知它必须处理数据的b $ b。

An idea I had was to have the main-thread or the plugin-threads insert
data in a thread-safe queue, and then send a signal to the recipient
(main or plugin depending on the data flow) to inform it has to process
the data.

....如果你不能谈论使用线程，

comp.programming.threads有一些非常很好的人可以帮助

这些细节。


-

Ben。

....and if you can''t be talked out of using threads,
comp.programming.threads has some very good people on it who can help
with any of these specifics.

--
Ben.

Ben Bacarisse写道：

Ben Bacarisse wrote:

comp.unix.programmer可能是一个合理的地方获得整体
$ b讨论了$ b设计。

comp.unix.programmer is probably a reasonable place to get the overall
design discussed.

感谢指示

Thanks for the direction

......如果你不能谈论使用线程，

...and if you can''t be talked out of using threads,

为什么每个人都非常讨厌线程:)我经常看不到

流程的优点小的东西。


再见

Alessio

Why does everybody hates threads so much :) I often fail to see the
advantages of processes for ''small'' things.

bye
Alessio

2008年10月21日11 ：34，在comp.lang.c中，Alessio Sangalli

（al******************@manoweb.com）写道：

On October 21, 2008 11:34, in comp.lang.c, Alessio Sangalli
(al******************@manoweb.com) wrote:

Ben Bacarisse写道：

Ben Bacarisse wrote:

[snip]

[snip]

> ...如果你不能谈论使用线程，

>...and if you can''t be talked out of using threads,

为什么每个人都讨厌线程这么多:)我经常看不到小事物的流程优势。

Why does everybody hates threads so much :) I often fail to see the
advantages of processes for ''small'' things.

< off-topic>

我的猜测是线程往往比它们的价值更麻烦。


考虑到程序创建进程的可能性（即api到

启动进程），线程是多余的。


在许多环境中，线程不提供任何执行速度优势

进程（线程的通常大参数是

上下文切换开销的线程比上下文切换''少''过程的开销为b $ b，但在许多系统中，线程和进程具有相同的上下文切换开销。）


线程通常需要比

进程更高级别的编程支持。


使用线程的程序经常受到影响从糟糕的设计/实现，

导致线程提供的任何优势丢失（我在想

死锁和竞争cond itions，以及未能解开逻辑）。


流程数据共享的有效方式与

线程和进程间有效数据共享通常会强制执行一定程度的数据

保护线程间数据共享避免。


HTH

< / off -topic>


-

Lew Pitcher


Master Code Code& JOAT-in-training |已注册的Linux用户＃112576
http://pitcher.digitalfreehold.ca/ |可根据要求提供GPG公钥

---------- Slackware - 因为我知道我在做什么。 ------

<off-topic>
My guess is that threads are often more bother than they are worth.

Given the possibility of programmed creation of processes (i.e. an api to
launch processes), threads are redundant.

In many environments, threads do not provide any execution-speed advantage
over processes (the usual "big" argument for threads is that "the
context-switch overhead for a thread is ''less'' than the context-switch
overhead for a process", but in many systems, threads and processes have
the same context-switch overhead).

Threads usually require a greater level of programming support than
processes.

Programs that use threads often suffer from poor design/implementation,
causing any advantage that threads offer to be lost (I''m thinking of
deadlock and race conditions, and of failure to disentangle logic).

There are as effective ways of data sharing for processes as there are for
threads, and inter-process data sharing usually enforces a level of data
protection that inter-thread data sharing avoids.

HTH
</off-topic>

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I''m doing. ------

这篇关于架构设计的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！