悉心沉淀，耐心坚持！

        很久以前就想写一些关于技术类的博文了，虽然自己真的很菜，但也想记下自己学习的过程，沉淀下自己所付出的努力，就在今天，就把之前自己花了一些时间完成的实验报告总结一下，算是自己的正式开始吧！

        题目：串行端口程序设计以及Linux多线程编程

实验环境：

1.Win7 + VirtualBox4.2.18

2.Ubuntu12.04

3.博创S3C2410开发板

    实验步骤：

  1.配置宿主机和目标机IP为同一网段，为挂载做准备。

2.挂载调试。

3.实验结果：

得到这个结果非常简单，在我回头看实现代码term.c时，我发现这个只是一个发送数据到串口进行显示的程序，在receive这个线程中，read(fd,&c,1)函数因为一直接受不到fd发过来 的数据会一直阻塞着，而此时的write(fd,&c,1)函数将会向fd发送数据从而显示在终端上，就是我们在上面看到的结果，此结果与receive线程、keyboard线程和串口COM2没有一点关系。

接下来可以对程序稍作修改，就能做好“回显”，即将send线程注释掉，在receive线程中将write(1,&c,1)改为write(fd,&c,1),这样receive线程就能接收并发送数据了，为了便于验证COM1端口只是负责接收指令，COM2才是负责收发数据，我在receive线程中多加了一个变量进行显示，代码如下：

实验结果如下：

实验的输入为：COM1：This is not echo!!!

              COM2：

接着将串口从COM1换到COM2，接着输入：SimplyImplement

第二行的COM2:后面的结果显示每按一个键都会在前面输出#，正是验证了前面提到的结论，很多同学都不知道为什么用两个口，认为只用一个口也能做回显，其实不然，我觉得这块是个很大的误区，所以单独提出来并做验证！但总体来说这种实验“回显”的方法实在是没什么技术含量，稍微懂点线程和串口知识的都没很快做出来，更何况老师给了我们如何改的文档···

下面我想谈谈自己用多线程是如何实现的，在参考了实验手册2.2的程序和在网上查了相关资料以及和同学请教和讨论了之后，我主要的思路和实验手册2.2的一样：

1.先定义1个互斥锁和2个条件变量

2.定义3个全局变量，一个用来存放数据，其他两个用来对读写进行控制。

readsign和writesign都初始化为0是为了之后的判断，保证先进行read再进行write。

3.receive线程

4.send线程

5.main函数没做任何变化

实验的输入为：COM1：This is not echo!

                COM2：

接着将串口从COM1换到COM2，接着输入：LinuxMulti-Thread

1.pthread_create主要是用来创建线程，创建成功则返回0，返回不为0则创建失败。当创建线程成功后，新创建的线程则运行参数三和参数四确定的函数，原来的线程则继续运行下一行代码；pthread_join则为用来等待一个线程的结束，这个函数式一个线程阻塞的函数，调用它的函数将一直等待被等待的线程结束为止，当函数返回时，被等待线程的资源被收回。

2.pthread_cond_wait(&cond1,&mutex)可以是线程阻塞在一个条件变量上，线程解开mutex指向的锁并被条件变量cond1阻塞；而pthread_cond_signal(&cond1)用来释放被阻塞在条件变量cond1上的一个线程。

3.pthread_mutex_lock(&mutex)为锁定互斥量；pthread_mutex_unlock(&mutex)为解锁互斥量。

最后想提到的一点就是read函数，读常规文件是不会阻塞的，不管读多少字节，read一定会在有限的时间内返回。从终端设备或网络读则不一定，如果从终端输入的数据没有换行符，调用read读终端设备就会阻塞，如果网络上没有接收到数据包，调用read从网络读就会阻塞，至于会阻塞多长时间也是不确定的，如果一直没有数据到达就一直阻塞在那里。同样，写常规文件是不会阻塞的，而向终端设备或网络写则不一定。