倒车轨迹研究

以前做车机的时候写的倒车轨迹推导过程,已经经过代码实现论证是可行的,在《摄像头坐标变换研究》中给出三个特殊地面坐标标定摄像头系数的方法。Word文档发布时公式靠上看起来很混乱,这里以截取图片的方式发布《倒车轨迹研究》文章如下:
阅读剩余部分 –

单一结构内存池

在写完成端口时Overlapped以及Socket需要重复回收再利用,设计了一种池的结构用于内存分配释放管理,后来遇到多线程间数据传递时,这种结构也适用。池结构使用map管理分配的内存,以内存地址为key,实际存放的值表示该内存是否被占用,使用vector存放回收空闲的内存,分配内存时若vector中有空闲则取出最后一个,从vector中取出最后一个效率比直接在map中查询第一个空闲的要高的多,在回收内存时需要定位到指定内存位置,使用map存储查询效率比直接遍历高。这里以之前文章中介绍到的可变缓冲区CXVarBuf为固定单一结构,给出内存分配释放管理池结构类。
阅读剩余部分 –

调试打印输出宏

调试程序时总是避免不了需要添加一些打印输出来确定问题,这里写了一个简单的调试打印输出宏。又检查了一遍代码,发现有的注释意义写错了,有的注释是复制后未进行修改,写代码时还是需要多注意细节。
阅读剩余部分 –

线程间数据传递–多对多队列CXMulToMulQueue

线程间数据传递有以下几种形式:

  • 一对一(入队出队严格有序);
  • 多对一(入队无序出队有序);
  • 一对多(入队有序出队无序);
  • 多对多(入队无序出队无序);

一对一适用于数据入队和出队被处理完成的顺序必须严格一致的情况,比如客户端Socket读线程读取数据解析包后交给主线程去处理,客户端逻辑处理对服务器下发包的顺序有严格依赖性,这里就必须使用这种一对一形式。

多对一这种形式典型的用于网关服务器把来自客户端数据转发给逻辑服务器,网关服务器会有多个工作线程用于并发接收来自客户端的数据,转交给与逻辑服务器建立连接的Socket写线程。

一对多这种形式多用于任务频率不会太高,任务相互对立且处理比较慢,需要开多个线程并发处理。

多对多这种形式用于任务相互对立,允许多个线程发起任务,同时会开启多个线程执行任务。

线程间数据传递通常传递的并不是数据本身而是数据存放的地址,传递地址相对于传递数据本身减少了数据拷贝过程,这里一定要保证传递的地址在数据被处理完之前不能够被销毁。比较容易想到的一种方式是发送数据时,在堆上申请一块内存并把数据拷贝到这块内存上,把地址发送出去,接收方处理完成后释放这块内存,如果数据传递频率很少使用这种方式没有问题,如果频率很高就会有很大问题,每次不断的申请和释放内存会浪费很多CPU资源,这种情况下需要采用内存池机制进行内存的申请和释放,内存池机制会在其他文章中介绍。

下面给出一个简单的多对多队列类,可以指定用于处理数据的工作线程数量,投递数据接口多线程安全。这里用于传递数据的队列使用临界区进行互斥访问,当有多个工作线程时必然会产生锁竞争,工作线程会由于需要等待锁消耗很多时间,后面使用完成端口内部的队列替代自己写的队列,把互斥访问交给系统去做,可有效减少由于锁竞争导致的耗时。
阅读剩余部分 –

线程的创建_beginthreadex

  • 使用_beginthreadex创建线程替换CreateThread;
  • 线程指针类型参数不能传递指向栈内的地址;
  • 创建线程返回的句柄在不使用时需要调用CloseHandle关闭;
  • 尽量保证线程内操作的数据都是由线程参数传入而不直接使用全局变量;
  • 线程内操作数据必须要确定是否需要进行加锁互斥访问;
  • 尽量保证线程正常优雅的退出;
  • 线程退出时确定是否需要对传入的参数进行释放;

示例代码如下:
阅读剩余部分 –

支持空间自动增长的可变缓冲区类CXVarBuf

很久以前写的支持自动增长的可变缓冲区类,当时处理数据时每次都需要申请释放,就写了这么一个类。后来才发现是自己重复制造了一个不怎么样的轮子,STL库中的string类不仅仅可以用作字符串类,还可以存放二进制数据,用起来更加简单方便,还是需要多看一些开源的代码,拓宽自己的眼界,可惜一直以来看的都不是很多,以后希望能够加强。

此类中使用了一个句柄来隐藏内部数据,站在使用者的角度去考虑问题,应该是只需要最少量的功能完备的简单接口,而不需要知道具体的数据及组织方式。
阅读剩余部分 –

项目代码管理目录结构

代码存放目录结构在实际项目开发中可能不太会被注意到,因为这对项目几乎不会有任何影响,但是层次分明的目录结构肯定看起来更加合理,每个部分在整个项目中是什么作用也会比较直观。之前公司项目进行过一次大的结构拆分,讨论出下文这种项目代码目录结构,本人业余时间写的代码和现在公司项目代码都是按这种目录结构管理的,个人认为还是一种比较好的代码管理方式。
阅读剩余部分 –

分类目录

文章归档