很支持云风的把纹理分为描述部分和数据部分，描述部分用来做说明资源的名称及加载方法及路径，已经纹理的其他信息比如mipmap，2D/3D/1D纹理等等；在此资源不需要使用或者内存紧张的时候可以释放数据部分。

如果没有引用计数，那么一个纹理被多个材质引用的时候如何去判断其是否能够被释放？

对于游戏的资源读取，是非常符合生产者和消费者的模型的，并且生产者和消费者都是唯一的（多个生产者没有意义，磁盘io是独占的）。锁无非是消费者——主线程每个循环主动的要求把读好的资源拿来锁那么一次，应该不需要考虑什么效率吧，而在我的设计模型中，可能和匿名的 Anonymous 相似，消费者主线程不操作io完全依赖生产者，其一是为了简单，其二我觉得2个线程都操作io，效率还不如一个，当然这完全是感觉，没有验证过。

看了一遍评论，对于Atry提供的方案比较认同，这也是我既将实施的一个方案，可能会作一些简化。

Cloud：我想请教一下，从文章来看，资源加载线程不可能是在主线程请求的时候才去读资源，因为主线程请求不到就会阻塞去加载资源，那么资源加载线程的预读是在什么时机发生的呢？

看了一遍评论，对于Atry提供的方案比较认同，这也是我既将实施的一个方案，可能会作一些简化。

Cloud：我想请教一下，从文章来看，资源加载线程不可能是在主线程请求的时候才去读资源，因为主线程请求不到就会阻塞去加载资源，那么资源加载线程的预读是在什么时机发生的呢？

跟文件系统挺类似的，不知道用到的小资源/文件多不多，如果多可以参考一下NTFS么，把小文件/资源的内容直接存储在文件头中，即NTFS中的$MFT文件存储有小于4K的文件的所有内容。

异步通讯也一样需要LOCK前缀保证其原子操作，只不过是在异步通讯实现模块中使用，例如win的消息通信

嘿嘿，西游地图预读那块，确实是复杂得很啊，不过懂了之后也就明白了。

02年我做过一个和这个类似的设计，也是在占用内存极大的情况下，设计换入换出。把一段时间没有使用的数据换出内存。当遇到需要使用的数据不在内存中的时候，再把它装载上来。不过都是同步的，没敢设计成异步操作。

不用锁的多线程，全部用异步通讯，这是最好的策略，它和低耦合的要求是一致的

也许Intel需要借鉴哈佛架构的思想，用硬件实现一些锁来提升多CPU环境下的锁性能。

Intel曾经在 IXP 2400/2800 系列的网络处理器中，采用了硬件的锁，效率很高。 可惜后来，网络处理器部门被卖掉了。

追本溯源，lock并不是因为有系统资源要在两线程间共享访问，而是因为对该系统资源(如内存区域）的操作不具原子性造成的。这是常引起误解的地方。

游戏中同时有多个消费者在现在几乎是不可能存在的。因为资源消费的最大头是在显卡，只有一块显卡的情况下，不会有多个线程同时把资源送向渲染管道。

即使有多个消费者，引用同样也是不必要的。因为只需要索取引用的时候资源可以即时载入就够了。我相信这样的设计对其它的应用也可以适应，比如你说的"海量视频数据" 。是淘汰算法决定了清除内存里的垃圾，让引用计数大于 0 的资源有不被淘汰的特权意义不大。

我认为当计算机的核越来越多以后，锁操作造成的性能降低会越来越明显。因为任意一个核上发起 lock 信号到总线，都会对其它核的工作流造成影响，这不是操作系统补丁可以解决的。只是现在我们才双核还看不出来。

加锁的程序段当然是非常轻量的，比如从链表中获取一个元素，向hash表中加个一个元素，复制一小段内存，这些好象都不会导致什么明显的阻塞吧。难道谁还会在加锁的程序段里做io操作么？另外，多线程的情况下部分线程临时等待也是没有问题的，因为cpu并未闲置，从总体速度来说并无降低，只是说稍微降低了平滑度。

cloud : 我指的资源管理池只负责已完全加载的内存资源，资源头不在其中。实现的就是一个自适应的资源read cache,在我的项目实际工作中还实现了write back cache。看来我误解了你的实现，按照我现在的理解，资源的消费者/游戏引擎实际大部分是单线程的，所以不存在多个消费线程共用的问题，也就不需要引用的模式。这样看来实现的还是一个简单的预读而已。

锁之所以慢，并不是因为加锁本身慢，而是因为加锁的位置可能产生瓶颈，多个线程都堵在那里，这样慢。

引用计数这个东西是首先可以拿掉的。因为资源数量是一定的，内存中保留的只是数据头，所以永远不释放也不会有问题。

其次不需要用队列来同步需要读取的数据。其实开一块共享内存一边生产请求，一边消费请求就足够了。

游戏里的需求有一个特殊之处：资源被引用的时候也需要被清出内存。这是因为，逻辑数据往往非常巨大，但是在当前帧的图象很可能不用渲染。数据就不需要加载。单纯靠引用计数来工作往往有两种结果，一种是引用加减变得非常频繁（提交到渲染管道前加引用，渲染完后立刻减引用），另一种是不能有效的释放资源。

不存在谁来释放资源的问题，也没有管理的问题。数据头本身是只加载不释放的，动态变化的只是数据本身。

批评谈不上，只是和我历来的做法和思路有所出入，提出来探讨一下而已。

象你描述的那读abcde这个思路在读入上当然是不需要任何lock的，问题主要是出在释放和引用上，如果资源读线程只负责读，而资源本身又是由申请/使用者自行负责管理的话，我看不到什么大的改进。

我自己的做法，是采用了 资源池+后台管理线程+后台资源预读线程 完成的。

每个资源都有自己的引用计数。 资源池是一个hash表，以资源guid为key保存全部在线资源的指针,后台管理线程定期按照某算法评价各个在线资源的生存优先度，并淘汰超过预留内存限制的refcount为0的优先度最低的资源。 所有需要在后台加载的资源列表加入后台预读线程的工作队列尾。 当主线程（或其他工作线程）需要某资源，则先在资源池中查找 * 假如找到，则返回一个引用并为其添加refcount,在使用完成后只减少计数，不释放内存。 * 假如没找到，则自行读取并加入资源池（资源池在加入过程中需要检查是否重复加入，如果存在重复，则释放新加入的资源，并返回旧资源的引用及增加记数）

后台预读线程从异步工作队列中提取请求，同样先在资源池中查找。

* 假如存在，则增加资源优先度。 * 假如不存在，则自行读入资源后加入资源池并赋予初始优先度（同样做重复性检查，只是这个情况不需要再添加引用记数）。

采用合适和优先度评价方法（综合使用次数，最后使用时间，占用内存大小及预读发生次数） ，可以比较好的自适应地降低内存消耗和磁盘IO。

而以上做法的瓶颈就是资源池的临时锁定和资源查找速度。锁定我是用临界量足够快（一秒一百万次只占1%cpu)，对于多核多U操作系统本身有补丁不用我操心，查找算法我的hash表足够大，hashvalue生成也有针对性，一般也就3，4步就找到。也不存在问题。

以上是我的做法，虽然是应用在海量视频数据的高速缓存服务中的，但是对游戏资源的管理也应该有效。无非是规模区别，本质相同。

哦，我当时用的是更粗放的办法来管理那个缓存，第一次请求的时候开始加载，长时间不用就删。好像也够用了。

后者是用资源依赖关系表决定的。

资源保存在外存里就有依赖关系表了。比如一个打包的模型，它天然就依赖贴图，骨骼等等别的数据。

又比如一张地图，依赖上面种的树，盖的房子。

这种依赖关系在运行时会被精简，不是所有依赖的东西都真的需要用到。

再说一下那个加载器吧。一个异步的加载器，是否使用了多线程，是否开了别的线程，对于主线程是透明的。主线程只知道资源加载完了有一个回调就行了，而这个回调是在主线程发生的，主线程不必知道资源加载线程的存在。

资源的缓存的逻辑也放到主线程比较方便。我最早试过把缓存的逻辑放到资源加载线程，这样主线程想要知道一个资源是否已经加载，就必须对资源加载线程有一个send操作来获取资源，实际上是行不通的。

不好意思，我之前看你文章看得不仔细。

如果程序需要 ABCDEF... 等资源，那么我们开两个线程读取它们。一个读 ABCDEF... ，一个在另外的内存空间读 A' B' C' D' E' F' ... （这个次序随着程序的运行，两者并不会一直保持相同）

前者只在需要的时候触发读操作，后者则持续的进行。所以，一般情况下后者总是先于前者把资源读进内存。

前者每次企图读特定资源的时候，比如需要 C ，只需要先检查一下 C' 是否存在就够了。

---------------------

请问后者读取哪些资源的算法是如何确定的呢？

其实提供的接口很简单的。一共两个步骤。

第一个步骤是初始化的时候，用一个字符串来获取一个资源信息的结构。

第二个步骤是渲染的时候，每需要用到一个资源，就用那个结构调一个require()函数。这个有可能返回空也可能能够得到具体的资源，但不管怎么样，都一定是立即返回。

当主线程获得这个资源以后，在这一帧里面，资源是能保证有效的。因为资源缓存的管理，资源的释放是在两帧之间干的。

对主逻辑来说，它根本不用管理资源的生命周期，它想要什么就请求什么（虽然不一定能请求到），经常用的东西自然会在内存里等着它用。

我想，让用户看到不完全的画面总比让用户什么都看不到，连鼠标都卡住不能动要好吧。

to 楼下的，如果用到 cmpxchg ，在多线程环境下依旧需要加上 LOCK 前缀，保证其原子操作。如果用了这个就不是 lockfree 了。

to Ricepig, 如果目录结构扁平，应该是 trie 的相对效率更低才对。因为在这个应用里，hash-map 的 key 全部变成了 DWORD ，（查询操作前的 string to key 转换是一次性的，多次重复查询只需要转换一次）。hash-map 是典型的空间换时间的结构，我理解的 trie 更多的是空间上的节省。一般来说 hash-map 的检索一个 O(1) 时间，这里还省略了 strcmp 的操作。所以无论 trie 组织的多么高效，一次 strcmp 是躲不掉了。

to atry: 我的需求是，是否多线程加载对逻辑来说是透明的。逻辑线程面对的接口就是一个可以立刻返回数据的接口。比如都进入 3d 渲染环节，当索取一个贴图的资源时，绝对不允许返回为空的。如果用回调来实现，交给程序员的接口就过于复杂了。

另外，我这里资源节点树只用于避免资源依赖关系表中资源对象在内存中的重复。判断数据是否加载是是用不到它的。还有就是，这个方案并不依赖消息队列来做线程间通讯。

to 不愿留名的批评家：

lock 操作会随着多核的发展，负担越来越严重。目前连真双核（独立 L1 cache）的机器都还是初步阶段，所以问题不那么明显罢了。我们这里有个同事在 freebsd 社区负责编写线程库，前段时间在新购置的四核主机上做测试，就发现和双核机器已大为不同。很多我们以前认为好的策略都变得相对坏了。多核时代程序员面临的问题会比我们曾经预想的糟糕。

这篇 blog 提到的方案之所以可以避免锁的使用，简单说来是这样的。

如果程序需要 ABCDEF... 等资源，那么我们开两个线程读取它们。一个读 ABCDEF... ，一个在另外的内存空间读 A' B' C' D' E' F' ... （这个次序随着程序的运行，两者并不会一直保持相同）

前者只在需要的时候触发读操作，后者则持续的进行。所以，一般情况下后者总是先于前者把资源读进内存。

前者每次企图读特定资源的时候，比如需要 C ，只需要先检查一下 C' 是否存在就够了。

整个过程由于并不存在需要同步的数据，所以不需要锁。

至于 C 和 C' 可能同时读取发生碰撞，我们只需要简单的允许两者同时存在于内存即可。这并不造成多大的浪费，原因有三：在需要读取的资源数量很大的时候，碰撞很难发生；单个资源体积不大，重复读取的量很小；操作系统对 I/O 操作本身有 cache 。

另外，win32里的临界量操作也是原子级别的，在未遇到互斥的情况下进入也是无lock的，速度非常接近lockfree算法，测试了1百万次循环 Enter,leave对，时间是10.5ms, 而lockfree的核心cmpxchg 跑1百万次是6.2ms,和单跑Enter速度一样。再考虑到遇到lock后运算时间较长（超过了线程切换消耗）的情况，我想使用哪个更加可靠和易懂应该是不言而喻了。

你搞错了吧？

稍微search下lockfree,貌似都是通过傻重试机制完成的，这样在对共享数据存在互斥操作本身比较耗时的情况下会导致cpu消耗成倍的增加。换句话说，这个机制只适合互斥访问频度非常高，而每次访问又非常短暂的情况下有效率提升，否则还不如通常的lock。

数据加载线程序可以不断的去完成队列中的数据加载请求，一旦加载完毕，就在资源结构中做好标记。而主线程收到数据使用请求时，检查到标记后直接把完整的数据指针复制过来即可。如果没有完成，则自行申请另一块内存，阻塞做数据加载。这样是为了避免冲突，当然也有可能浪费，两条线程恰巧加载同一份资源。由于单个资源体积都不大，这点时间浪费是可以接受的，而空间在数据回收阶段可以完全收回。

<hr/> 这一点跟我所作的（http://www.ac.net.blog.163.com/blog/static/13649056200741255845585/）不太一样。我不会那么麻烦去做可以不做的事情，我让主线程绝不阻塞，如果没有那个资源就跳过。我这么做程序复杂度比你低，用户体验也比主线程自己阻塞加载要好。

我的实现，主线程的资源指针是资源加载线程把资源加载完以后的，主线程自己在回调函数里面修改的。而这个回调函数是发起一次请求的时候主线程交给资源加载线程，然后资源加载线程在加载完以后再post给主线程运行的。资源指针在post以后，所有权转移给主线程。

判断一个资源是否加载到内存里面，用hash表或者类似的技术查找一般来说不能满足网络游戏或者类似应用的效率要求。所以不得不让逻辑线程持有资源的标示信息，在这个结构里面他根据判断指针是否为空之类的办法来判断一个资源是否加载。这样效率才行得通。

关于lock-free programming和transactional memory, http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=332有提到。

关于trie和hash，得看你的hash算法效率了。如果目录结构不太深的话，也就是trie扁平，应该效率和hash差不多。

我认为这里在 key-value 里用单词查找树来保存这些字符串没有多少好处。上面列出来的用唯一指针的方式做 key 效率要高很多。

trie 对相似的大量字符串的保存有优势。在字符串池本身的储存上可以考虑使用 trie 。我用的 hash-map 只是为了实现上的方便。

我觉得写一些免锁的多线程程序，在多核 CPU 下之所以依旧需要一些 cpu 指令的支持，比如 intel 提供的 LFENCE/SFENCE/MFENCE 指令，这皆是因为现在的 CPU 开始不保证读写次序以及多核 CPU 上开始存在多个 cache 的缘故。我们的算法本身并无过错。

而锁机制最终要调用 LOCK 指令，发送 LOCK# 信号到总线，这就低效的多了。

感谢提供资料，tharris 的主页正在看。英文上我不太理解前面提到的东西的区别，我暂时关心的是不用锁机制来解决问题。也就是最终代码是否需要产生 LOCK# 信号。个人认为通过良好的设计，是完全可行的。

至于 MFENCE 这样的指令的调用，以后完全可能被编译器支持，放入 volatile 的实现中。

无锁数据结构是以前的研究热点，但是后来被证明很多公开发表文章里的实现方法都是错误的，transactional memory是目前的研究热点，见：http://research.microsoft.com/~tharris/

免锁的多线程，除了没有资源共享之外，只能靠cpu指令了，这样的代码更加没有美感吧。

另外，在资源树中，既然字符串重复出现次数很多，为啥不用trie？

申请和释放应该放在同一线程内，这样就可以了。只把加载的过程放在线程池里去做。

免锁的数据结构及算法是当今多核时代程序员们的重要研究课题。google 一下 lock free 可以得到大量的信息。

另,多线程设计起来复杂度并不高,但是早期一定要设计好,因为后面的调试会很困难.分离好任务流,安排好汇合点,一切其实很明了.

没听说过lockfree的多线程设计，只要线程之间有数据关联,则必然有交叉点需要做保护.好的线程任务分配模式可以减少交叉点,但是不可能消灭交叉点.另外,临界量的进出消耗是可以忽略不计的(每秒百万次级别以上).

如果你这个实现无lock,那么必然在资源的释放上产生歧义,也许释放者正准备淘汰一个资源而申请者正好得到了它..

确实！多线程的复杂度和单线程不是一个数量级的～

我今天才知道，原来用消息队列有一个专有名词叫lock-free，又学到一个名词！

我前段时间也做过类似的工作。

不错哦