开发

异或运算(XOR)特点:

X xor X = 0
X xor 0 = X
X xor Y = Y xor X
(X xor Y) xor Z = X xor (Y xor Z)

利用异或可以巧妙地实现一些玩意,例如:
不用中间临时变量交换两个整数;
XOR linked list:只用一个指针实现双向链表

 

最近在折腾将系统升级成64位。

目前主要碰到两个问题:

(1) 指针和整形转换的问题

(2)long,unsigned long在32位下为32位,在64位下为64位。

对于1,应该采用intptr_t或者uintptr_t。

我采用了luajit的声明(呵呵,作者的注释很有趣):

#if defined(_MSC_VER)
/* MSVC is stuck in the last century and doesn’t have C99’s stdint.h. */
typedef __int8 int8_t;
typedef __int16 int16_t;
typedef __int32 int32_t;
typedef __int64 int64_t;
typedef unsigned __int8 uint8_t;
typedef unsigned __int16 uint16_t;
typedef unsigned __int32 uint32_t;
typedef unsigned __int64 uint64_t;
#ifdef _WIN64
typedef __int64 intptr_t;
typedef unsigned __int64 uintptr_t;
#else
typedef __int32 intptr_t;
typedef unsigned __int32 uintptr_t;
#endif
#elif defined(__symbian__)
/* Cough. */
typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
typedef long long int64_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
typedef unsigned long long uint64_t;
typedef int intptr_t;
typedef unsigned int uintptr_t;
#else
#include <stdint.h>
#endif

对于2,用int或者unsigned int替换之。

 

后来发现网上这篇文章不错:

http://www.oracle.com/technetwork/cn/server-storage/solaris/ilp32tolp64issues-137107-zhs.html

虚拟机的一些坑

这段时间开发我们的跨服系统,踩了虚拟机的两个大坑:

一是时间问题。有的时候会出现时间忽快忽慢的问题,甚至时间倒退。当然,我们服务器程序本身也有一些API使用不当的地方,如QueryPerformanceCounter(winserver2003),gettimeofday(Linux).

二是性能问题。我们的服务器在虚拟机上跑,性能跟非虚拟机上相差非常大(大型MMORPG)。

这个和虚拟机的类型,配置,操作系统和应用程序可能都有一定的关系。

跟某些同学交流,目前有的做法是新服流量大,对性能要求高,才会放在物理机上,其它的还是放在虚拟机上。

双刃剑啊。。。

项目中的跨(区)服国战功能一直不稳定,之前一直没有上线。这段时间在排查这个问题。

其中有一个严重的隐患昨天才发现。抽象一下是这样的:A, B, C 三个线程,在处理网络消息时对一些共享变量根本不作同步。

这个问题在时间一大,压力一大的时候就会引起各种不稳定问题。

早上躺在床上想了想,A,B,C线程已有的一些锁已经把一些设计搞的很复杂了,如果加上线程间嵌套调用,用锁的话,只会把问题搞的很复杂。

根据实际的情况,目前的想法是:

(1 )把A,B之间的处理都统一到B中处理,A与B做到完全隔离;

(2 )B和C很难完全隔离,用消息队列进行通信。虽然也会用到锁,但是只会锁住队列。

嗯,明天搞起。

最近由于机器原因,服务器开发迁移到了一个新的环境。

然而以前运行很好的服务突然崩溃,出现如下错误:

Program terminated with signal SIGKILL, Killed.
The program no longer exists.

(gdb) bt
No stack.

然后,

cd /var/log
more messages | tail

果然,最后几条显示:

Sep 22 10:06:11 localhost kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

显然,应该是内存分配引起的问题。查看swap,崩溃阶段为0,更加印证了这一点。

查看程序的相关配置,启动了太多的内容,导致内存分配失败,而程序中又没有捕捉这些错误。去掉一些内容后,程序又恢复好了。