==相關產品==
Detail Information...
這是中華電信的贈品...XD
機能還蠻強的...
NVRAM和DRAM都具備256MB...
我沒看過裡面..
但我猜測應該是Intel的CPU...
Session可以吃到35000左右
(不過最新的資安艦隊2010..
新提供的機器機能更強..
還具備UTM..
Session可以吃到10萬..0_0)
這算是Geteway...
因為提供的功能已經遠超過OSI Layer3了
不過他的3.5G function好像是optional...
既然拿到了...
就要好好把玩了...XD
由於之前有玩過Zyxel的產品了...
Interface差不多就是那個死樣子..
10/06/2009
Intel的I/OAT網路加速技術...
Type：
網路技術
Source:
http://www.intel.com/network/connectivity/vtc_ioat.htm
最近有幸拿了一塊Supermicro的x58板子...
I/OAT已經說到第二版本了.
所以我又拿了Intel Xeon W3570來測試...
因為I/OAT中其中一個DCA技術必須要具備...
然後Mainboard必須要具備QuickData技術..
這是I/OAT的建立基礎....
結果試一試發現都開不起來...
從I/OAT Checker顯示的結果...
OS不符合要求XD...
他需要我去灌Windows 2k3/2k8阿阿阿..囧...
再來就是Intel 82574L的GbE晶片不完整支持I/OAT...
搞笑喔..
那幹嘛板子BIOS提供I/OAT的function...XD...
4/16/2009
豐富的裝飾者 - Decorator Pattern
Type：
Designed Pattern
咖啡太苦?恩..加糖..
沒有奶味?..那加奶精吧..
我要加甚麼就加甚麼...
Decorator模式使您個體多樣化...
Decorator提供多重物件的裝飾..
事實上，他是非常有用的Pattern..
應當好好學起來...!!
假定一個生活化的案例:
一家工廠製造一台車(Car)...
在製造的過程中...
其實是不斷的加工...
例如加上引擎..
加上輪框..
加上車胎等等...
而引擎也是一個不斷加工後所產生的一件元件....
Decorator Pattern就是像上述這樣的例子...
根據Decorator Pattern的正式定義如下:
Decorator Pattern可以動態將責任加諸在物件上，若要擴充模組，裝飾者提供了比繼承更有彈性的選擇
所謂從責任加諸在物件上..
意味著，責任就是傳遞需要使用的物件，裝飾在裝飾!
....待續一下..拖個稿..=.="
沒有奶味?..那加奶精吧..
我要加甚麼就加甚麼...
Decorator模式使您個體多樣化...
Decorator提供多重物件的裝飾..
事實上，他是非常有用的Pattern..
應當好好學起來...!!
假定一個生活化的案例:
一家工廠製造一台車(Car)...
在製造的過程中...
其實是不斷的加工...
例如加上引擎..
加上輪框..
加上車胎等等...
而引擎也是一個不斷加工後所產生的一件元件....
Decorator Pattern就是像上述這樣的例子...
根據Decorator Pattern的正式定義如下:
Decorator Pattern可以動態將責任加諸在物件上，若要擴充模組，裝飾者提供了比繼承更有彈性的選擇
所謂從責任加諸在物件上..
意味著，責任就是傳遞需要使用的物件，裝飾在裝飾!
....待續一下..拖個稿..=.="
4/15/2009
UML設計 - Class Diagram的 "屬性" 介紹
Type：
UML設計
我們根據Addison-Wesley的UML精華第三版內容來探討..
首先講幾個部分..
UML的最大目的在當初也是針對軟體工業而產生的..
從最初標準混亂的時代...
到UML出現終於有一個共通的標準
軟體發展才得以持續下去..
不過要先知道..
其意義不在圖的價值，而是他所表達出來的 商業效益 或著 內容..
廢話不多說...
基本上類別圖(ClassDiagram)是編程人員最常使用的一種圖形表示法..
他基本上可以表達三個部分...
在OOP上..
我們可以說屬性可以是基本型別(Primitive Type)的變數或著他代表一個物件(Object)..
在目前流行的程式語言(ex: C#、Java)上..
通常物件是參照(Reference)的表示形式...
我們來看看下圖對於屬性的圖形表示:
Grady Booch這個粗體字表示為類別(Class)的名稱...
其中，中間的內容為屬性(Attribute)的表示內容...
來看看屬性文字敘述的正式定義:
visibility name: type multiplicity = default {property-string}
visibilty 表示的是屬性的可見範圍，大多可以是Public、Private或著Protected
name 當然就是屬性的名稱
type 表示屬性的型態，例如:String(string)、Boolean(bool)、int(Integer)、byte等等...
multiplicity 表示為多重性，例如:一對一、一對多等等...
可以有
我們以後再來講...
default 當然就是表示當沒有值的時候，預設值為多少。這很簡單，不需做任何解釋!...
{property-string} 表示當其他表示法不夠表達時，可以用這段來補充額外的屬性..
但是property-string的表達方式有很多種，我們以後再來談!
最後，再從圖上來..
其中+和-的符號表示為public和private的可見性修飾詞，而protected則是用#表示..
[ ]裡面數值表達多重性
最後=符號後面接的是預設值..
圖形表示的方式很簡單..
至於，我們對應其程式碼如下:
class GradyBooch{
public String name="Grady Booch";
public String birthday;
public String[] phone;
public bool sex;
private String father;
private String mother;
}//end GradyBooch
程式碼的表達大概就是這樣子..
以上差不多就是這樣!
首先講幾個部分..
UML的最大目的在當初也是針對軟體工業而產生的..
從最初標準混亂的時代...
到UML出現終於有一個共通的標準
軟體發展才得以持續下去..
不過要先知道..
其意義不在圖的價值，而是他所表達出來的 商業效益 或著 內容..
廢話不多說...
基本上類別圖(ClassDiagram)是編程人員最常使用的一種圖形表示法..
他基本上可以表達三個部分...
- 類別性質(Property)
- 類別操作(Operation)
- 限制條件(Constraint)
而類別的特徵(Feature)正是包含了性質和操作...
然而類別性質又分為: 屬性(Attribute)和關聯(Relation)這邊部分要談的就是屬性這塊..
屬性通常可以表達物件的 狀態...
在OOP上..
我們可以說屬性可以是基本型別(Primitive Type)的變數或著他代表一個物件(Object)..
在目前流行的程式語言(ex: C#、Java)上..
通常物件是參照(Reference)的表示形式...
我們來看看下圖對於屬性的圖形表示:
Grady Booch這個粗體字表示為類別(Class)的名稱...
其中，中間的內容為屬性(Attribute)的表示內容...
來看看屬性文字敘述的正式定義:
visibility name: type multiplicity = default {property-string}
visibilty 表示的是屬性的可見範圍，大多可以是Public、Private或著Protected
name 當然就是屬性的名稱
type 表示屬性的型態，例如:String(string)、Boolean(bool)、int(Integer)、byte等等...
multiplicity 表示為多重性，例如:一對一、一對多等等...
可以有
- 1:表示一對一
- *:表示無上限也無下限
- 0..1:最多至一種，也可能沒有半個
我們以後再來講...
default 當然就是表示當沒有值的時候，預設值為多少。這很簡單，不需做任何解釋!...
{property-string} 表示當其他表示法不夠表達時，可以用這段來補充額外的屬性..
但是property-string的表達方式有很多種，我們以後再來談!
最後，再從圖上來..
其中+和-的符號表示為public和private的可見性修飾詞，而protected則是用#表示..
[ ]裡面數值表達多重性
最後=符號後面接的是預設值..
圖形表示的方式很簡單..
至於，我們對應其程式碼如下:
class GradyBooch{
public String name="Grady Booch";
public String birthday;
public String[] phone;
public bool sex;
private String father;
private String mother;
}//end GradyBooch
程式碼的表達大概就是這樣子..
以上差不多就是這樣!
ASP.NET Http Pipeline
Type：
ASP.NET
這個是ASP.NET Http Pipeline架構..
重點是他乘載的是CLR Environment..
也就是Managed-Code...
在CLR之前都是透過一連串的COM-Level(Unmanaged Code)元件不斷的調用..
有時間..
會講講這塊流程..!!
4/14/2009
Defraggler 1.09.138
Type：
Application
Official Site Link
Changelog:
- New search feature.
- Various tweaks to the drive list.
- Improvements to freespace calculation when moving large files.
- Improved handling of of sparse files.- Lots of minor UI tweaks.
Changelog:
- New search feature.
- Various tweaks to the drive list.
- Improvements to freespace calculation when moving large files.
- Improved handling of of sparse files.- Lots of minor UI tweaks.
第二命名規則:Pascal Case
Type：
Programming
從之前的Camel Case介紹可以得知，Pascal Case就是Upper Camel Case..
從wiki摘出來的說法是:
Upper Camel Case
每一個單字的首字母都採用大寫字母，例如：FirstName、LastName、CamelCase，也被稱為 Pascal 命名法
他不是很難，因為他跟Lower Camel Case的差異僅是Upper Camel Case的開頭第一個單字為大寫而已..!!
從wiki摘出來的說法是:
Upper Camel Case
每一個單字的首字母都採用大寫字母，例如：FirstName、LastName、CamelCase，也被稱為 Pascal 命名法
他不是很難，因為他跟Lower Camel Case的差異僅是Upper Camel Case的開頭第一個單字為大寫而已..!!
4/13/2009
第一命名規則:Camel Case
Type：
Programming
中文就是駱駝命名法啦...!!
根據微軟的部分說法是這樣的:
識別項的第一個字母是小寫的，而每個隨後串聯文字的第一個字母是大寫的。例如：
backColor
根據Wiki的說法是:
Camel Case的詞語來自Perl語言普遍使用的大小寫混合格式...
而 Larry Wall 等人所著的暢銷書《Programming Perl》（O'Reilly 出版）的封面圖片正是一匹駱駝。」
Camel Case的限制條件，不得使用下列表式:
Lower Camel Case
第一個單字以小寫字母開始；第二個單字的首字母大寫，例如：firstName、lastName
Upper Camel Case
每一個單字的首字母都採用大寫字母，例如：FirstName、LastName、CamelCase，也被稱為 Pascal 命名法
我個人對命名的看法:
Low Camel Case
==一個字以內:==
test、color、execute、observer、singleton、factory、measurements、time、connection、stop、start、run
==兩個字情況:==
getName、setProperty、executeReader、backColor、startRunning、nationalLanguage、dataBase、threadConnection、windowFrame、actionListener、windowAdapter
==三個字情況:==
getId、getSn、setNo、lastIndexOf、trimToSize、createSystemObject、removeArrayList
==四個字以上:==
全寫出來或著
setHRDepartment、addNewWorkProject、newProcessId、destroySid、rebuildNewThread
根據微軟的部分說法是這樣的:
識別項的第一個字母是小寫的，而每個隨後串聯文字的第一個字母是大寫的。例如：
backColor
根據Wiki的說法是:
Camel Case的詞語來自Perl語言普遍使用的大小寫混合格式...
而 Larry Wall 等人所著的暢銷書《Programming Perl》（O'Reilly 出版）的封面圖片正是一匹駱駝。」
Camel Case的限制條件，不得使用下列表式:
- 單字之間不得空格，ex:back Color
- 不可使用底線區隔，ex:back_Color
- 不能使用連接符號連接單字之間，ex: back-Color
Lower Camel Case
第一個單字以小寫字母開始；第二個單字的首字母大寫，例如：firstName、lastName
Upper Camel Case
每一個單字的首字母都採用大寫字母，例如：FirstName、LastName、CamelCase，也被稱為 Pascal 命名法
我個人對命名的看法:
- 盡量不要使用縮寫，最好能在兩個單字內搞定
- 非得需要縮寫的話，請表達語意清楚，或著附加註解..!
Low Camel Case
==一個字以內:==
test、color、execute、observer、singleton、factory、measurements、time、connection、stop、start、run
==兩個字情況:==
getName、setProperty、executeReader、backColor、startRunning、nationalLanguage、dataBase、threadConnection、windowFrame、actionListener、windowAdapter
==三個字情況:==
getId、getSn、setNo、lastIndexOf、trimToSize、createSystemObject、removeArrayList
==四個字以上:==
全寫出來或著
setHRDepartment、addNewWorkProject、newProcessId、destroySid、rebuildNewThread
Gof的基本Designed Pattern意見..
Type：
Designed Pattern碎碎念..
Design Pattern總共分為三大類:
對於新手應該從以下Pattern切入較為適當..
學習難度都不是很高..
當然如果覺得Gof的書本身就枯燥乏味、不是很好看(他確實是不好看..!)..
那麼O大師有趣的Designed Pattern書籍是不錯的選擇之一...
>>Creational Mode
>>Structural Mode
>>Behavioral Mode
按照Gof的Designed Pattern書籍..對於新手應該從以下Pattern切入較為適當..
- Abstract Factory
- Composite
- Factory Method
- Strategy
- Adapter
- Decorator
- Observer
- Template Method
學習難度都不是很高..
當然如果覺得Gof的書本身就枯燥乏味、不是很好看(他確實是不好看..!)..
那麼O大師有趣的Designed Pattern書籍是不錯的選擇之一...
我對委由(delegate)的基本看法..!!
Type：
Designed Pattern
基本上就是透過delegate...
可以達到彈性化的行為呼叫....
而不必被綁得死死的...
我們可以擁一種簡單的部分代碼表示..
public abstract class Cpu{
protected CpuInstruction cpuInstruction;
protected String type;
//skip...
public void executeInstruction(){
cpuInstruction.execute();
}//end executeInstruction
//skip...
}//end Cpu
//-------------------------------------
public class AmdCpu extends Cpu{
public AmdCpu(string type){
cpuInstrcution=new X86Instruction();
this.type=type;
}//end constructor
public void printType(){
System.out.println("CPU Type: "+this.type);
}//end printType
}//end AmdCpu
由上可以看到executeInstruction()是一個委由(delegate)的方法..
而他的行為決定則是由次類別(AmdCpu)來決定..
因此並不會一開始就被綁死..
這樣做是極具彈性了..
不過上述程式碼的缺點就是"行為實踐"不夠彈性罷了!!
可以達到彈性化的行為呼叫....
而不必被綁得死死的...
我們可以擁一種簡單的部分代碼表示..
public abstract class Cpu{
protected CpuInstruction cpuInstruction;
protected String type;
//skip...
public void executeInstruction(){
cpuInstruction.execute();
}//end executeInstruction
//skip...
}//end Cpu
//-------------------------------------
public class AmdCpu extends Cpu{
public AmdCpu(string type){
cpuInstrcution=new X86Instruction();
this.type=type;
}//end constructor
public void printType(){
System.out.println("CPU Type: "+this.type);
}//end printType
}//end AmdCpu
由上可以看到executeInstruction()是一個委由(delegate)的方法..
而他的行為決定則是由次類別(AmdCpu)來決定..
因此並不會一開始就被綁死..
這樣做是極具彈性了..
不過上述程式碼的缺點就是"行為實踐"不夠彈性罷了!!
Adapter Pattern的轉接結構
Type：
Designed Pattern
Adapter Pattern對於不同介面之間可以提供相容的轉換..
這是一種非常有用的設計..
例如:
舊版的列舉器轉換成新的迭代裝置(Iterator)...
生活化一點..
例如美規接口透過一個轉接器(Adapter)轉換成歐規接口..
這樣的一種概念其實不難懂...
相對的，他的實作也是很容易...!!
來談談範例:
我們以建立一個匯流排結構PCI介面..
假設並沒有實際設計PCI的具象實踐(Instance)...
僅有一個PCIe的具象實踐..
客乎要求我們必須以PCIe架構建立在早期的PCI架構上..
1.首先我們建立一個介面以作為超型別(Super-Type)之應用..
public interface IPciInterface {
public void link();
public void read();
public void write();
}//end IPciInterface
2.我們得知有一個Pcie具象實踐可以使用，並且他是實作於IPcieInterface介面..
public class Pcie implements IPcieInterface{
public void link(){
System.out.println("Linking!");
}//end link
public void read(){
System.out.println("Reading!");
}//end read
public void write(){
System.out.println("Writing!");
}//end write
}//end Pcie
3.為了符合客戶的需求，我們建立一個PcieToPci的轉接器(Adapter)..
public class PcieToPci implements IPciInterface{
private Pcie pcie;
public PcieToPci(Pcie pcie){
this.pcie=pcie;
}//end constructor
public void link(){
pcie.link();
}//end link
public void read(){
pcie.read();
}//end read
public void write(){
pcie.write();
}//end write
}//end PcieToPci
4.建立好PciToPci轉接器後，再將剩下的Client部分處理..
public class Main{
public static void main(String args[]){
Pci pcie=new Pcie();//Pcie的具象實踐
PcieToPci pcieToPci=new PcieToPci(pcie);
//operations
pcieToPci.link();
pcieToPci.read();
pcieToPci.write();
}//end main
}//end Main
以上是一個非常簡單的Adapter Pattern應用..
他並不難..
學習起來也很快!!...
大概就這樣..
這是一種非常有用的設計..
例如:
舊版的列舉器轉換成新的迭代裝置(Iterator)...
生活化一點..
例如美規接口透過一個轉接器(Adapter)轉換成歐規接口..
這樣的一種概念其實不難懂...
相對的，他的實作也是很容易...!!
來談談範例:
我們以建立一個匯流排結構PCI介面..
假設並沒有實際設計PCI的具象實踐(Instance)...
僅有一個PCIe的具象實踐..
客乎要求我們必須以PCIe架構建立在早期的PCI架構上..
1.首先我們建立一個介面以作為超型別(Super-Type)之應用..
public interface IPciInterface {
public void link();
public void read();
public void write();
}//end IPciInterface
2.我們得知有一個Pcie具象實踐可以使用，並且他是實作於IPcieInterface介面..
public class Pcie implements IPcieInterface{
public void link(){
System.out.println("Linking!");
}//end link
public void read(){
System.out.println("Reading!");
}//end read
public void write(){
System.out.println("Writing!");
}//end write
}//end Pcie
3.為了符合客戶的需求，我們建立一個PcieToPci的轉接器(Adapter)..
public class PcieToPci implements IPciInterface{
private Pcie pcie;
public PcieToPci(Pcie pcie){
this.pcie=pcie;
}//end constructor
public void link(){
pcie.link();
}//end link
public void read(){
pcie.read();
}//end read
public void write(){
pcie.write();
}//end write
}//end PcieToPci
4.建立好PciToPci轉接器後，再將剩下的Client部分處理..
public class Main{
public static void main(String args[]){
Pci pcie=new Pcie();//Pcie的具象實踐
PcieToPci pcieToPci=new PcieToPci(pcie);
//operations
pcieToPci.link();
pcieToPci.read();
pcieToPci.write();
}//end main
}//end Main
以上是一個非常簡單的Adapter Pattern應用..
他並不難..
學習起來也很快!!...
大概就這樣..
4/10/2009
Singleton Pattern概要..!!
Type：
Designed Pattern
Singleton Pattern目的用來創造獨一無二的資源...
這是非常有用的結構..
例如:
針對撰寫系統..
假設我們透過Factory Pattern來撰寫獨一無二的DataBaseFactory..
來進行對DataBase的統一存取...
這時透過Singleton Pattern便可以建立獨一無二的Factory..
可以看看簡單的代碼範例:
class Singleton{
private Singleton(){
}//end constructor
public static Singleton getInstance(){
return new Singleton();
}//end getInstance
}//end Singleton
由上可以看出幾個要點:
1.constructor必須private防止外部建立多個instance
2.一定要搭配static關鍵字
3.本身是可以返回自有的constructor
但是上述依然不夠完美..
我們把它改寫成如下:
class Singleton{
private static Singleton uniqueInstance;
private Singleton(){
}//end constructor
public static Singleton getInstance(){
if(uniqueInstance==null)
uniqueInstance=new Singleton();
return uniqueInstance;
}//end getInstance
}//end Singleton
可以看出這樣的方式可以做到對Singleton物件的唯一性..
但是如果想到Multi-Thread情況..
他依然還是有問題:
1.容易造成資源取得先後順序問題
2.容易造成資訊錯誤的災難
我們可以透過synchrnized關鍵字來建立critical section..
如下這樣:
class Singleton{
private static Singleton uniqueInstance;
private Singleton(){
}//end constructor
public static synchronized Singleton getInstance(){
if(uniqueInstance==null)
uniqueInstance=new Singleton();
return uniqueInstance;
}//end getInstance
}//end Singleton
但是要注意一點:
synchronized對於Mutli-Thread效能是有衝擊的..
因此必須要考量..!!
我們可以採用雙重鎖來盡量減少多次的同步化
如下做法:
class Singleton{
private volatile static Singleton uniqueInstance;//volatile關鍵字可以表是變數的同一存取
private Singleton(){
}//end constructor
public static Singleton getInstance(){
if(uniqueInstance==null){
synchronized(your_class_name.class){
if(uniqueInstance==null) uniqueInstance=new Singleton();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end Singleton
以上便是很簡單的Singleton應用..!!
這是非常有用的結構..
例如:
針對撰寫系統..
假設我們透過Factory Pattern來撰寫獨一無二的DataBaseFactory..
來進行對DataBase的統一存取...
這時透過Singleton Pattern便可以建立獨一無二的Factory..
可以看看簡單的代碼範例:
class Singleton{
private Singleton(){
}//end constructor
public static Singleton getInstance(){
return new Singleton();
}//end getInstance
}//end Singleton
由上可以看出幾個要點:
1.constructor必須private防止外部建立多個instance
2.一定要搭配static關鍵字
3.本身是可以返回自有的constructor
但是上述依然不夠完美..
我們把它改寫成如下:
class Singleton{
private static Singleton uniqueInstance;
private Singleton(){
}//end constructor
public static Singleton getInstance(){
if(uniqueInstance==null)
uniqueInstance=new Singleton();
return uniqueInstance;
}//end getInstance
}//end Singleton
可以看出這樣的方式可以做到對Singleton物件的唯一性..
但是如果想到Multi-Thread情況..
他依然還是有問題:
1.容易造成資源取得先後順序問題
2.容易造成資訊錯誤的災難
我們可以透過synchrnized關鍵字來建立critical section..
如下這樣:
class Singleton{
private static Singleton uniqueInstance;
private Singleton(){
}//end constructor
public static synchronized Singleton getInstance(){
if(uniqueInstance==null)
uniqueInstance=new Singleton();
return uniqueInstance;
}//end getInstance
}//end Singleton
但是要注意一點:
synchronized對於Mutli-Thread效能是有衝擊的..
因此必須要考量..!!
我們可以採用雙重鎖來盡量減少多次的同步化
如下做法:
class Singleton{
private volatile static Singleton uniqueInstance;//volatile關鍵字可以表是變數的同一存取
private Singleton(){
}//end constructor
public static Singleton getInstance(){
if(uniqueInstance==null){
synchronized(your_class_name.class){
if(uniqueInstance==null) uniqueInstance=new Singleton();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end Singleton
以上便是很簡單的Singleton應用..!!
Java中的Deadlock情況!!
Type：
Programming
要知道deadlock的前提:
Thread A占用Resource B
Thread B占用Resource A
發生情況:
Thread A將Resource B鎖定(lock)住
;同時,
Thread B將Resource A鎖定(lock)住
Thread B要取用Resource B，結果Thead A仍未處理完，要等待!
Thread A要取用Resource A，結果Thread B仍未處理完，要等待!
最終，雙方同時等待造成Deadlock!
模擬Deadlock:
1.雙方同時sleep以致不會把lock object交還..
2.Thread A的sleep時間比Thread B長
(這樣做Thread B，會以為Thread A還在處理..!因為lock object沒交還..)
3.使用synchronized關鍵字來創造critical section..
代碼如下:
public class Main{
public static void main(string args[]){
Thread threadA=new Thread(new ThreadA());
Thread threadB=new Thread(new ThreadB());
threadA.start();
threadB.start();
}//end main
}//end Main
class ThreadA implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
Thread.sleep(150);
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadA
class ThreadB implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
Thread.sleep(50);
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadB
//------------------------------------------------------------------
//class Resource使用Singlaton Pattern來創造獨一無二的Resource
class ResourceA{
public volatile static ResourceA uniqueInstance;//控制統一鎖
private ResourceA(){
}//end constructor
public static ResourceA getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceA_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceA();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceA
class ResourceB{
public volatile static ResourceB uniqueInstance;//控制統一鎖
private ResourceB(){
}//end constructor
public static ResourceB getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceB_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceB();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceB
//------------------------------------------------------------------
Thread A占用Resource B
Thread B占用Resource A
發生情況:
Thread A將Resource B鎖定(lock)住
;同時,
Thread B將Resource A鎖定(lock)住
Thread B要取用Resource B，結果Thead A仍未處理完，要等待!
Thread A要取用Resource A，結果Thread B仍未處理完，要等待!
最終，雙方同時等待造成Deadlock!
模擬Deadlock:
1.雙方同時sleep以致不會把lock object交還..
2.Thread A的sleep時間比Thread B長
(這樣做Thread B，會以為Thread A還在處理..!因為lock object沒交還..)
3.使用synchronized關鍵字來創造critical section..
代碼如下:
public class Main{
public static void main(string args[]){
Thread threadA=new Thread(new ThreadA());
Thread threadB=new Thread(new ThreadB());
threadA.start();
threadB.start();
}//end main
}//end Main
class ThreadA implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
Thread.sleep(150);
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadA
class ThreadB implements Runnable{
ResourceA resA=ResourceA.getInstance();
ResourceB resB=ResourceB.getInstance();
public void run(){
synchronized(resA){
System.out.println("ResourceA for ThreadA is starting!");
Thread.sleep(50);
synchronized(resB){
System.out.println("ResourceB for ThreadA is starting!");
}//end synchronized
}//end synchronized
}//end run
}//end ThreadB
//------------------------------------------------------------------
//class Resource使用Singlaton Pattern來創造獨一無二的Resource
class ResourceA{
public volatile static ResourceA uniqueInstance;//控制統一鎖
private ResourceA(){
}//end constructor
public static ResourceA getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceA_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceA();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceA
class ResourceB{
public volatile static ResourceB uniqueInstance;//控制統一鎖
private ResourceB(){
}//end constructor
public static ResourceB getInstance(){
if(uniqueInstance==null){
synchronized(your_class_for_ResourceB_name.class){
if(uniqueInstance==null)
uniqueInstance=new ResourceB();
}//end synchronized
}//end if
return uniqueInstance;
}//end getInstance
}//end ResourceB
//------------------------------------------------------------------
12/29/2008
[閒閒沒事幹0002]繼承的汎生問題
Type：
Programming
從之前的繼承範例來看..
可以看出繼承雖然可以帶來reuse的特性..
但他同樣發生了一些不合理的情況..
在這個情況下..
第一個解決要訣:要將容易變動的地方抽離出來..
從該範例來看，目前變動區域為:
public void getName(String name){
System.out.println(name);
}
如果說能將其讓getName()獨立出來的話..
就可以避免Info類別再次被修改..
也變的更有彈性..
可以看出繼承雖然可以帶來reuse的特性..
但他同樣發生了一些不合理的情況..
在這個情況下..
第一個解決要訣:要將容易變動的地方抽離出來..
從該範例來看，目前變動區域為:
public void getName(String name){
System.out.println(name);
}
如果說能將其讓getName()獨立出來的話..
就可以避免Info類別再次被修改..
也變的更有彈性..
12/28/2008
[閒閒沒事幹0001]OOP的繼承..!
Type：
Programming
這是一個基礎的教學..
一般OOP的繼承可以達到重複性利用的特性..
以一個範例來看:
public class Info{
public void getName(String name){
System.out.println(name);
}
public void getInfo(){
System.out.println("This is a information!");
}
}
class Main extends Info{
public static void main(String args[]){
Main main=new Main();
main.getInfo();
main.getName("Main");
}
}
以一個上述範例來看..
這樣作便可達到重複利用的特性...
不過繼承必須要適時的情況下用...
上述範例並不是一個很好的應用..
因為他可能汎生的問題如下
public class PartInfo extends Info{
}
對PartInfo而言..
他只是想要取得getInfo()..
很可惜的..
getName()的方法對PartInfo而言也必須強迫繼承..
如果說從Info再另行修改以可能會造成牽一髮動全身的嚴重後果..
因此對整個軟體設計而言..
這是不得不去注意的...
11/05/2008
11/03/2008
New:PotPlayer
Type：
Application
http://www.pcdvd.com.tw/showthread.php?t=823877
http://tvpot.daum.net/
不能多國語言(對岸有額外提供簡體版)..
稍微看了一下濾鏡文件...
ffcodec.dll (看到ff兩個字的人應該知道他是以甚麼為基礎了吧..)...
估計就是這一個了...
這player雖然說支持DXVA(還可以調DXVA Level..這個MPC-HC沒有..)..
不過目前現階段來說...
目前這DXVA也是有問題的...
這東西看起來是很方便..
但是我不建議對這方面操作不是很熟悉的人玩...
因為依然還是要調整...
尤其是Splitter部分(不調對於某些情況就會出現問題了..例如某些格式的影片，你用它的內置Splitter會發生嚴重延遲現象..!!根本沒辦法看..)...
還有dxva默認是關閉的
因為解出來的畫面有問題..
例如VC-1會慘死..完全沒畫面!!
H.264解出來有時會發生色塊異常現象..
古老的MPEG2解出來則完全沒問題..!..
另外這款支持Multi-Thread..
但是默認也是關閉的...
最後VideoRender..
用Vista的人要強制調成EVR(C/A)..
(那裏寫成EVR(無渲染)..可是我記得我之前看TechNet的開發文件，EVR沒有在分這個了，算了!管他的......)
否則默認會是VMR9-Renderless..
我個人自己的結論:
這東西玩玩就好...
==補充==
後來用一用...
終於讓VC-1(DXVA)解出來了..
但是還是沒法全程看下去..
因為問題還是很大...
http://tvpot.daum.net/
不能多國語言(對岸有額外提供簡體版)..
稍微看了一下濾鏡文件...
ffcodec.dll (看到ff兩個字的人應該知道他是以甚麼為基礎了吧..)...
估計就是這一個了...
這player雖然說支持DXVA(還可以調DXVA Level..這個MPC-HC沒有..)..
不過目前現階段來說...
目前這DXVA也是有問題的...
這東西看起來是很方便..
但是我不建議對這方面操作不是很熟悉的人玩...
因為依然還是要調整...
尤其是Splitter部分(不調對於某些情況就會出現問題了..例如某些格式的影片，你用它的內置Splitter會發生嚴重延遲現象..!!根本沒辦法看..)...
還有dxva默認是關閉的
因為解出來的畫面有問題..
例如VC-1會慘死..完全沒畫面!!
H.264解出來有時會發生色塊異常現象..
古老的MPEG2解出來則完全沒問題..!..
另外這款支持Multi-Thread..
但是默認也是關閉的...
最後VideoRender..
用Vista的人要強制調成EVR(C/A)..
(那裏寫成EVR(無渲染)..可是我記得我之前看TechNet的開發文件，EVR沒有在分這個了，算了!管他的......)
否則默認會是VMR9-Renderless..
我個人自己的結論:
這東西玩玩就好...
==補充==
後來用一用...
終於讓VC-1(DXVA)解出來了..
但是還是沒法全程看下去..
因為問題還是很大...
Media Player Classic HomeCinema (x86), svn 855
Type：
Application
http://xvidvideo.ru/
Revision 855 - Directory Listing
Modified Sun Nov 2 19:54:36 2008 UTC (13 hours, 6 minutes ago) by casimir666
Revision 854 - Directory Listing
Modified Sun Nov 2 16:12:19 2008 UTC (16 hours, 48 minutes ago) by clsid2
Revision 853 - Directory Listing
Modified Sun Nov 2 13:09:56 2008 UTC (19 hours, 50 minutes ago) by casimir666
Revision 852 - Directory Listing
Modified Sun Nov 2 12:36:50 2008 UTC (20 hours, 24 minutes ago) by casimir666
Revision 851 - Directory Listing
Modified Wed Oct 29 20:40:26 2008 UTC (4 days, 12 hours ago) by casimir666
Revision 855 - Directory Listing
Modified Sun Nov 2 19:54:36 2008 UTC (13 hours, 6 minutes ago) by casimir666
Fix : broken DXVA with nVidia boards
Revision 854 - Directory Listing
Modified Sun Nov 2 16:12:19 2008 UTC (16 hours, 48 minutes ago) by clsid2
Updated FFmpeg Revision 853 - Directory Listing
Modified Sun Nov 2 13:09:56 2008 UTC (19 hours, 50 minutes ago) by casimir666
FIXED : support for H264 interlaced video for DXVA decoder
Revision 852 - Directory Listing
Modified Sun Nov 2 12:36:50 2008 UTC (20 hours, 24 minutes ago) by casimir666
Fixed : support for H264 interlaced video for DXVA decoder Revision 851 - Directory Listing
Modified Wed Oct 29 20:40:26 2008 UTC (4 days, 12 hours ago) by casimir666
Simplified Chinese translation updated
Subscribe to:
Posts (Atom)