执行时间变得无法预测？！ [英] execution time becomes unpredictable?!

问题描述

可能会偏离主题，但我不知道在哪里发布这个问题。希望

一些机构清除了我的怀疑。


编码标准我正在研究的项目说'不要用
使用malloc。当我问我的领导时（我刚开始工作）他说我们

不应该在实时系统中使用动态分配，代码将不会在可预测的时间段内运行。任何人都可以告诉他什么是b $ b意味着什么？为什么执行时间变得不可预测？ br />

谢谢

Might be off topic but I don''t know where to post this question.Hope
some body clears my doubt.

The coding standard of the project which I am working on say''s not to
use malloc.When I asked my lead(I have just started working) he said we
should not use dynamic allocation in real time systems, the code will
not run in predictable time period.Can anybody tell what does he
mean?Why the execution time becomes unpredictable?

Thanks

推荐答案

va ****** @ rediffmail.com 写道：

va******@rediffmail.com wrote:

可能会偏离主题但我不知道在哪里发布这个问题。希望
有些机构清除了我的怀疑。

我正在研究的项目的编码标准说'不是
使用malloc。当我问我的领导时（我刚刚开始工作）他说我们<不应该在实时系统中使用动态分配，代码将无法在可预测的时间段内运行。任何人都可以告诉他/他的意思是什么？为什么执行时间变得不可预测？

谢谢

Might be off topic but I don''t know where to post this question.Hope
some body clears my doubt.

The coding standard of the project which I am working on say''s not to
use malloc.When I asked my lead(I have just started working) he said we
should not use dynamic allocation in real time systems, the code will
not run in predictable time period.Can anybody tell what does he
mean?Why the execution time becomes unpredictable?

Thanks

因为找到一块内存的时间正确，所以会有所不同。自系统永远运行以来，

课程，如果由于碎片导致

malloc失败，您的系统会怎么做。

Because the time to find a block of memory the correct size will vary. Of
course since the system runs "forever", what will your system do if a
malloc fails due to fragmentation.

在文章< 11 ********************* @ f14g2000cwb.googlegroups中。 com>，

< va ****** @ rediffmail.com>写道：

In article <11*********************@f14g2000cwb.googlegroups. com>,
<va******@rediffmail.com> wrote:

可能会偏离主题，但我不知道在哪里发布这个问题。希望
一些机构清除了我的怀疑。
我正在研究的项目的编码标准说'不要使用malloc。当我问我的领导时（我刚刚开始工作）他说我们不应该使用在实时系统中进行动态分配，代码将无法在可预测的时间段内运行。任何人都可以告诉他/他的意思是什么？为什么执行时间变得不可预测？

Might be off topic but I don''t know where to post this question.Hope
some body clears my doubt. The coding standard of the project which I am working on say''s not to
use malloc.When I asked my lead(I have just started working) he said we
should not use dynamic allocation in real time systems, the code will
not run in predictable time period.Can anybody tell what does he
mean?Why the execution time becomes unpredictable?

在一般情况下，线索是正确的，但不是 - 不可避免地如此。


malloc（）的问题通常是由
搜索一个空闲列表，寻找一个足够大的块（在对齐约束之后）。如果内存严重碎片化，那么可能会有很多可用内存，但可能需要很长时间才能找到一块已知足够长的块。


类似地，取决于free（）操作的智能程度，返回一块内存的

程序可能涉及合并

邻近地区;这可能反过来引发更多的合并，因为在回收中花费了无限的时间。


free（）在合并相邻区域方面的工作量越多记忆，

确定性的时间是不确定的 - 但是如果它没有做到b / b
合并，那么malloc（）和亲属最终会花费很多时间一点时间

搜索并且可能合理地决定没有可用的内存

即使剩下足够的可用空间。


一些free（）impliment促使合并，直到malloc（）请求

进来可以通过合并而不是单独来满足。

在这种情况下， free（）可能很快，但每隔一段时间malloc（）可能会花费相当多的时间来支付
。

我相信有些版本的malloc（ ）和free（）周围有

上限时间。例如，malloc（）可以将内存分成

一系列固定大小的池，并且总是返回适合的最小的
池。如果池的大小为2的幂，则可以使用简单的

位图来发现池成员是否可用

，并且返回池成员可以来简单地说'或'在
a中说这个元素是免费的。必须调整此池策略

以允许足够大小的池成员，这可能是在初始化时完成一次的b
。如果有必要提供更多的小条目，有一些变化将会破坏更大的池：

这使得时间更不确定，但算法可以

被初始化以对其执行此深度的最大限制设置

to，从而对malloc（）/ free（）时间设置最大限制。

当您使用实时系统时，可能会有一些

区域，其中绝对速度很重要，但是 - 通常 -

真实 - 时间系统更关心的是-bredictability-

响应时间而不是纯粹的速度。必须在这么多毫秒内处理一个中断

- 因此，对于低优先级的垃圾收集，你不能被耽搁几个

秒。

处理中断不一定需要很长时间

（这可能涉及非常少的计算），但对于

"实时系统通常不得不在事件触发后的相对较短的时间内发生
。

-

警告：可能包含一些坚果。

In the general case, the lead is correct, but not -inevitably- so.

The problem with malloc() is that usually it is implimented by
searching through a free list looking for a chunk of a large enough
size (after alignment constraints). If memory is badly fragmented,
there could be a lot of available memory but it might take a long time
to find a chunk known to be long enough.

Similarily, depending on how smart the free() operation is, the
procedure for returning a chunk of memory might involve merging together
adjacent regions; that could in turn trigger more merging, for an
indefinite amount of time spent in reclamation.

The more work that free() does to merge adjacent areas of memory, the
less deterministic the time it will take is -- but if it does not do
merging, then malloc() and kin could end up taking quite a bit of time
to search and could plausibly decide that there is no available memory
even though there are plenty of mergable spaces left.

Some free() implimentations hold off merging until malloc() request
comes in that could be satisfied by merging but not by itself alone.
In that case, free() might be fast, but every once in a while malloc() could
take quite a bit of time.
There are, I believe, versions of malloc() and free() around that have
upper bounds on time. For example, malloc() could divide memory into
a series of pools of fixed size, and always return the smallest
pool that fits. If the pools are sized as powers of 2, then simple
bitmaps can be used to discover whether a pool member is available
or not, and returning a pool member can come out as simply or''ing in
a bit to say the element is free. This pool strategy has to be tuned
to allow for enough of the right size of pool members, which might be
done once at initialization time. There are some varients that will
crack apart larger pools if necessary to provide more small entries:
this makes the timing less deterministic, but the algorithm can
be initialized to place a maximum limit on the depth it will do this
to, thus placing a maximum limit on the malloc()/free() time.

When you are working with real-time systems, there may be some
areas where sheer speed is important, but -generally-
"real-time systems" are more concerned with -predictability- of
response times than with sheer speed. An interrupt must be handled
within so many milliseconds -- so you can''t be held up for several
seconds on garbage collection for something low priority. The
handling of the interrupt will not necessarily take very long
(it might involve very little computation as such), but for
"real-time systems" that not-very-long-time usually has to happen
within a relatively short time from the event trigger.
--
Warning: potentially contains traces of nuts.

Peter Nilsson写道：

Peter Nilsson wrote:

va ****** @ rediffmail.com 写道：

va******@rediffmail.com wrote:

可能会偏离主题，但我不知道在哪里发布这个问题。

Might be off topic but I don''t know where to post this question.

comp.programming也许。

comp.programming perhaps.

希望有些机构清除我的怀疑。
我正在研究的项目的编码标准说'不要使用malloc。当我问我的主角（我刚开始工作）时他说我们不应该使用动态分配真正的时间系统，代码将无法在可预测的时间段内运行。

Hope some body clears my doubt.

The coding standard of the project which I am working on say''s
not to use malloc.When I asked my lead(I have just started
working) he said we should not use dynamic allocation in real
time systems, the code will not run in predictable time period.

您的回复已经解释了原因，但您的领导的担忧是令人惊讶的鉴于真实时间系统是用Java和其他使用垃圾收集的语言实现的。

在关键系统中，主要关注的是如果动态分配失败该怎么办。

You have responses already explaining why, but your lead''s
concerns are surprising given that real time systems are
implemented in Java and other languages that use garbage
collection.

In critical systems, the main concern is what to do if a
dynamic allocation fails.

实际上，许多实时系统都是用C / $
和C ++以及其他没有的语言实现的br $>
垃圾回收。


正如其他人所说，垃圾收集和内存

碎片是实时的噩梦/>
关键系统。在有经验的程序员中，即使是堆栈分配也会导致
颤抖;他们担心超过有限的堆栈区域。


-

托马斯马修斯


C ++新闻组欢迎辞：
http：// www.slack.net/~shiva/welcome.txt

C ++常见问题： http://www.parashift.com/c++-faq-lite

C常见问题： http://www.eskimo.com/~scs/c-faq/top.html

alt.comp.lang.learn.c-c ++ faq：
http://www.comeaucomputing.com/learn/faq/

其他网站：
http://www.josuttis.com - C ++ STL图书馆书籍
http：//www.sgi。 com / tech / stl - 标准模板库

Actually, many real-time systems are implemented in C
and C++ as well as other languages that don''t have
garbage collection.

As others have stated, garbage collection and memory
fragmentation are a nightmare for real-time and
critical systems. Even stack allocation causes
trembles in experienced programmers; they are
worried about overruning a limited stack area.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book
http://www.sgi.com/tech/stl -- Standard Template Library

这篇关于执行时间变得无法预测？！的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！