1. 有两个问题关于c语言线程进程的，还望高手解答
程序的进度是以线程为单位向前推进的，很显然线程属于某一进程，进程拥有了程序实例的基本资源，在单核处理器的情况下，显然系统中只能有一个线程在执行，而在多核的情况就有些复杂了，要看程序与系统如何处理。
你说的锁应该是线程互斥量的使用，一般对于临界代码会使用类似于下面的代码
pthread_mutex_lock(&mysql_mutex);
// some critical code ...
pthread_mutex_unlock(&mysql_mutex);
其实系统中的锁并不是加给了要访问的资源或执行的代码，而是创建的互斥量，如果代码不使用下面的机制
pthread_mutex_lock(&mysql_mutex);
// some critical code ...
pthread_mutex_unlock(&mysql_mutex);
直接
// some critical code ...
这肯定是可以执行的，但是这背离了我们使用锁的初衷。
加锁进程对一互斥量加锁之后，是直接执行临界代码的，然后再释放互斥量，如果另一线程需要执行临界代码，同时又使用了锁的机制，那么它就会检查互斥量是否被锁住，如果被锁住会阻塞等待，若不是，就会为互斥量加锁，并随之进入临界代码，最后释放互斥量。
2. python GIL 和 线程锁是不是同一个东西
今天看到一篇文章，讲述的是几个提升python性能的项目:传送门
在看的过程中，接触到一个名词，一个从学python开始就一直看到，但是从来都是一知半解的名词，心里不开心，必须把它搞明白，对了，这个词就是 GIL。网上搜索了一些资料，粗浅的理解了什么是GIL，自己感觉学习的过程比较好，感觉略有收获，老规矩，为了巩固知识，自己整片文章出来写一写，其实好多文章已经写的很完善了，所以这篇随笔，只做知识巩固，如有雷同，请各位原创作者原谅，小菜鸟一枚，如果哪里写的有问题，还请各位前辈不吝指正。
一句话：解决多线程之间数据完整性和状态同步的最简单方法自然就是加锁。
首先，GIL的全名，Global Interpreter Lock，鉴于英文水平，不做名词翻译，以免误导。大体解释一下，这个锁就是用来为了解决Cpython多线程中线程不安全问题引入的一个全局排它锁，它的作用就是在多线程情况下，保护共享资源，为了不让多个线程同时操作共享资源，导致不可预期的结果而加上的锁，在一个线程操作共享资源时，其他线程请求该资源，只能等待GIL解锁。这个设置在Cpython刚引入多线程概念的时候就有了，然后后续的各种包和组件开发都不可避免的受到了GIL的影响，所以有人会说，python在多线程处理的时候很慢。python GIL实现方式类似于如下伪代码：
if __name__ == '__main__':
GIL锁开始运作
主线程做操作
主线程完成操作
GIL锁释放资源
所以多线程共同操作共享资源的时候，有一个线程竞得了资源，它就被GIL锁保护起来，其他线程只能是在那里等着，但是这个时候，线程的休眠唤醒，全部会消耗CPU资源，所以嘞，就会慢。
看到这个时候，我又发现了一个名词：线程安全。这个名词，也是那种特别熟悉，但就是无法清晰的说出它是啥的概念。查了资料，在这记一下：
线程安全就是多线程访问时，采用了加锁机制，当一个线程访问该类的某个数据时，进行保护，其他线程不能进行访问直到该线程读取完，其他线程才可使用。不会出现数据不一致或者数据污染。 线程不安全就是不提供数据访问保护，有可能出现多个线程先后更改数据造成所得到的数据是脏数据。
我自己想了一下，大约就是这样，比如整个列表，俩个线程同时在列表中append操作，如果没有锁的保护，在机缘巧合之下，俩个线程同时先后申请了空间且没来得及插入数据，然后这时列表中只会有一个空间，那么在插入过程中只能有一个数据写入，会造成不可知后果，有可能报错终止，有可能有一个线程操作没成功，那么这个就是线程不安全了，大白话说，只要线程之间没有共享资源，那么就是线程安全的，有共享资源，为了保证线程安全，需要引进锁的机制。
而后的文章中，有前辈做过实验：
过程证明了因为GIL的存在，导致python在使用多线程的时候反而不如顺序执行快。
此处我又温习了一下python线程：
线程的顺序执行还是多线程并发，取决于join函数的位置。join函数的作用是等待当前线程结束，所以每一个线程创建之后，调用start函数，这是在后面跟上该线程的join函数，那么就是顺序执行，如果多个线程先完成创建和start，最后加上join函数，那么就变成了多线程并发。
这就是今天的学习内容，其实所有知识网上都能找到，更想分享的是一种学习的方法，一种本身很不推荐的学习方法，那就是类似于探索性测试的学习，啥不懂就去看啥，有些时候，我们学习东西确实不能非要究其内在，软件行业的学习本身在非本行人事看来就特别神奇且枯燥，所以最初的学习，我们需要整个图形界面，让我们学到的东西有了成就感，如果上来先去研究机器码，那么没几个人愿意学下去，但是不管怎样，既然走上了软件行业的道路，这种探索性，打破砂锅问到底的学习，在我的感觉里应该是必经之路，也就是所谓的底层研究。以安卓开发举例，如果做安卓开发的，虽然能写出很漂亮的界面，解决所有的bug，如果不了解安卓系统linux层的知识，在我的眼里，从未把这种研发看做大牛。当然我并不觉得不了解linux底层的安卓研发可以解决任何bug
当下的软件行业进入了一个神奇的阶段，我已经听过无数遍的理论，培训机构出来就能赚钱，大学读着没用，在这里不讨论教育体制问题，从个人情感上，我觉得大学教育虽然没有教给学生直接找工作的技能，但是给了所有学生一个能够了解基础知识的园地，换而言之，作为行业的一员，总应该有将行业发展起来的觉悟，行业内整体风气，缺乏静下心来的沉淀。在大谈敏捷，行为驱动，机器学习的同时，自己需要静下心来回头看看，基础已然不牢，再走下去是否有些危险。是不是学习软件技术，就是为了获取互联网行业那虚高的工资，是否已经局限于第三方框架，一旦框架出现问题，只能打给客服而束手无策，是否有过没有做任何尝试就将bug归咎于安卓系统，阿里中间件等等，是不是旧技术还没用明白，为了新技术就可以不再去研究。
还是小菜鸟，在此大谈行业发展难免有些放肆，如有不对的地方，还请各位前辈不吝指正
3. 为什么有人说 Python 的多线程是鸡肋
多线程还是有用的，多进程有多进程的好处，多线程有多线程的好处。
多进程稳定，启动时开销大点，但如果你的运行时间远大于多进程的时间，用多进程比较方便，如postgresql用多进程，chrome 多进程。
如果你只是想做个定时器样的简单东西，对稳定性要求低些，如vb,c#类似的定时器，用多线程吧，但线程的同步要注意了。python的线程更加类似定时器，python的线程不是真线程，但有的场合用这种定时器也能解决很多问题，因为开销小，开启也方便。
进程和线程，一个是重量级的，一个轻量级的，重量级的进程有保护区，进程上下文都是操作系统保护的，而线程是自己管理，需要一定的技术，不能保证在并发时的稳定性（多进程也不稳定，但很容易看出来，因为多出了进程容易发现），而python的更像是定时器，定时器有时也可以模拟线程，定时器多时的开销比线程的开销要小，真线程有下上文开销，一个操作系统启动多进程和多线程会达到切换饱和是有数量的，真线程或进程太多都会导致cpu占用率居高不下，而定时器可以开n多。
很多东西不是一种比另外一种先进，而是一种互补的关系，计算机的计算单位切换有优点必有缺点，关键在找到合适的使用方式扬长避短。
4. 高手进，关于C语言在windows上建立多线程的问题（VC6.0上实现）
原因 是 在使用CreateThread 会造成一些 资源的无法释放 比如c++对象
当然原因不止这些 还很有几个 详情 你可以参考windows核心编程
5. （C语言中）互斥锁的死锁问题
如果你将mutex_c换成mutex_p,则不会死锁,因为,你第一个线程锁上后,切换到第二个线程,因为mutex_p未释放,第二个线程无法获取mutex_p,进入等待状态,此时OS将再次调度第一个线程,直到第一个线程释放mutex_p之后,第二个线程才会被激活,然后调试第二线程,获取mutex_p.
使用OS提供的互斥量来保护公共资源还是比较安全的,但如果用二值信号量的话,就可能会有优先级反转的情况.
6. 谁知道C++项目如何避免线程死锁
要避免死锁那么首先应该知道死锁产生的四个条件
死锁产生的四个必要条件：
何为必要条件？
产生死锁，必然四个条件成立；四个条件成立，不一定为死锁
1互斥
只有互斥才可以产生死锁，两个进程共同操作一个资源，那么，同一时间只能一个进程来操作，那么另一个进程必须等待，此进程不释放，另一个永远等待。产生死锁
2不可以强占
两个进程，一个进程占有某一个资源，另一个不可以强行占有我的资源，如果可以占有，那么两个进程都可以操作资源，那么就不会产生死锁。
3请求保持
我请求某一个资源的同时，保持对另一个资源的占有。那么我不释放，那么另一个进程才可能等待；如果释放，那么共同操作同一个资源，不会等待，也就不会死锁。
4循环等待
a等待b的释放资源，b等待c释放资源，c却等待a释放资源。都在循环等待。
那么避免死锁就是要避免上述情况的出现
7. C语言：多线程(phread)中如何处理链表的增加、更新、删除节点
两者都可以～ 用线程锁会稍稍简单一些，不过如果对链表的操作很频繁的话性能会比较差（一个链表一个锁）～
8. java线程锁有几种
1、自旋锁
2、自旋锁的其他种类
3、阻塞锁
4、可重入锁
5、读写锁
6、互斥锁
7、悲观锁
8、乐观锁
9、公平锁
10、非公平锁
11、偏向锁
12、对象锁
13、线程锁
14、锁粗化
15、轻量级锁
16、锁消除
17、锁膨胀
18、信号量