Mitzyuki's Blog

C 言語の変数定義

C 言語の変数定義は宣言部に若干クセがあるのでまとめました。

ローカル変数

変数のスコープが宣言されたブロックの内側に限定される変数です。 ブロックとは { と } の内側などで、一番判りやすいのは関数の宣言部分です。

以前は変数宣言はブロックの先頭のみで可能でしたが ISO/IEC 9899:1999 (C99) から任意の場所の変数宣言が可能となっています。

  1int     foo(void)
  2{
  3
  4    int     i;
  5
  6    i = 0;                  /* ローカル変数 */
  7
  8    {
  9        int     j;          /* ローカル変数 */
 10            :
 11    }
 12
 13    /* ここでは j は参照できない */
 14
 15}
    

ローカル変数の特徴を以下に示します。

• スコープ (有効範囲)は宣言されたブロック内に限られます。
• 関数の呼び出しごとに新しく確保され関数から戻るときに破棄されます。
• 実体は基本的に後述するスタック上に置かれます。
• 初期化しないと値は不定で内容は保証されていません。

グローバル変数

関数の外で宣言する変数です。

  1int     status;                 /* グローバル変数 (初期値は 0) */
  2
  3int     foo(void)
  4{
  5
  6    if(status == 1){            /* ファイル内のどこからでも参照できる */
  7        :
    

グローバル変数の特徴を以下に示します。

• スコープはファイル全体です (extern を宣言する事で他ファイルからもアクセス可能)。
• プログラム開始時に確保され終了するまで存在し続けます。
• 明示的に初期化しなくても自動的に 0 で初期化されます。
• 実体は実行ファイル内の「データ領域」に配置されます。

グローバル変数のうち、初期値を持つものは .data セグメント、 初期値を持たないもの (自動で初期化されるもの) は .bss セグメントに割り当てられるのが一般的です。

メモリレイアウトとスタック

典型的なプロセスのメモリ空間はアドレスの低い方から高い方へおおよそ次のように並びます。

ヒープとスタックが互いに向かって伸びていくため、両方が使いすぎて衝突すると「スタックオーバーフロー」などの問題が起きます。

スタックの動作(スタックフレーム)

関数を呼び出すたびに、スタック上に「スタックフレーム」と呼ばれる領域が積まれます。中身はおおよそ次のようなものです。

• 呼び出し元に戻るためのリターンアドレス
• 呼び出し元のベースポインタの退避値(スタックフレーム同士を辿るため)
• 引数(レジスタ渡しの場合もあります)
• その関数のローカル変数

具体的なスタック利用の流れ

  1int     add(int a, int b)
  2{
  3
  4    int result = a + b;     /* ローカル変数はこの関数のスタックフレームに置かれる */
  5
  6    return result;
  7    
  8}
  9
 10int     main(void)
 11{
 12
 13    int x = 3,
 14          y = 4;
 15    int z = add(x, y);      /* add() 呼び出し時に新しいスタックフレームが積まれる */
 16
 17    printf("%d\n", z);
 18
 19    return 0;
 20    
 21}
            

1. main() が呼ばれるとスタックに main() 用のフレームが積まれ(プッシュ)、 スタック上に変数 x、y、z が確保されます。
2. 関数 add(x, y) が呼ばれるとスタックにリターンアドレスなどを積んだ上で さらに add() 用のフレームが積まれ、引数 a、b、変数 result が確保されます。
3. add() が return するとそのフレームはスタックから取り除かれ(ポップ)、 制御は main() に戻ります。 add() のローカル変数 (a、b、result) はこの時点で消滅します。
4. main() が return すると、main() のフレームも取り除かれます。

この様な構造のため関数 add() で定義された変数 result は add() の外では参照できませんし、 参照しても値は保証されていません。

ダングリングポインタによる BUG

関数 add() を少し変更して文字列を操作する関数に変えてみます (例示のためなのでチェック処理やエラー処理などは実施していません)。

  1char    *add(char *a, char *b)
  2{
  3
  4    char    result[1024];               /* ローカル変数はこの関数のスタックフレームに置かれる */
  5
  6    snprintf(result, sizeof(result), "%s%s", a, b);
  7
  8    return result;
  9
 10}
 11
 12int     main(void)
 13{
 14
 15    char    *x = "foo",
 16            *y = "bar";
 17    char    *z = add(x, y);         /* 関数 add() のローカル変数を参照 */
 18
 19    printf("%s\n", z);
 20
 21    return 0;
 22    
 23}
            

関数 add() はローカル変数 result のアドレスをリターンしていますが、 前述の通り result はスタック上に確保された変数のため add() のリターン後は値は保証されません。 リターンした値はスタックのアドレスを示していますが値は保証されていません。 そのため z の値は不定となってしまいます。 関数からローカル変数をリターンする場合は必ず値をリターンする必要があります。 C 言語の仕様として配列の名前を参照した場合は配列の先頭要素を指すアドレスとして扱われますので特に注意が必要です。 この様にローカル変数のアドレスをリターンする事をダングリングポインタと呼びます。

再帰とスタックオーバーフロー

このLIFO (Last In First Out) 構造のおかげで、 関数呼び出しが何段ネストしても各関数は自分専用の変数領域を持てますし、 再帰呼び出しでも呼び出し回数分のフレームが積み重なるだけで正しく動作します。 逆に言うと、再帰が深すぎたり、ローカルに巨大な配列を確保しすぎたりすると、 このスタック領域を使い切って「スタックオーバーフロー」を起こします。

  1void    recurse(int n)
  2{
  3
  4    char    buf[1024 * 1024];           /* 1関数呼び出しごとに 1MB 消費 */
  5
  6    recurse(n + 1);                     /* 再帰呼び出し (すぐにスタックが尽きる) */
  7
  8}
            

とは言っても再帰呼び出しする場合は staic 変数は BUG の原因となるので、 再帰呼び出しの可能性がある場合は static 変数は使わない方が良いです。

以下は static 変数を利用したために不正な値となってしまう階乗計算処理です。

  1int     count(int n)
  2{
  3
  4    static  int total = 0;              /* すべての再帰で共有される */
  5    
  6    total *= n;
  7    if(n > 0)
  8        count(n - 1);                   /* 再帰呼び出し */
  9
 10    return total;
 11
 12}
 13
 14int     main(int argc, char *argv[])
 15{
 16
 17    printf("%d\n", count(atoi(argv[1])));
 18
 19    return 0;
 20
 21}
            

この様な BUG の温床になってしまう事もあるので、 特に最近では再帰呼び出し自体を悪だとする風潮もある様ですが 再帰呼び出し便利なんですよね...ついつい使ってしまいます。

static 宣言

C 言語の static 修飾子は文脈によって複数の意味と効果を持っているので初心者の頃は混乱しがちです。 そもそも複数の効果を持つ修飾子を同じ名前にするな...と Dennis に言いたい。

関数内の static 変数

関数の内部での static 修飾子は記憶クラスを定義します。 static 指定の変数を定義すると変数は前述のデータ領域に置かれ関数が終了した後も値が保持されますが、 変数のスコープはローカル変数同様にブロックの内部のみとなっています。 以下の関数 foo() では最初に呼ばれた時のみ変数 i が 0 で初期化され、 呼び出し毎に i がインクリメントされます。 2 回目の呼び出しでは i は 2 に、10 回目の呼び出しでは i は 10 となります。 当然ですが関数 foo() の外側では i は参照できません。

  1int     foo(void)
  2{
  3
  4    static  int     i = 0;          /* 変数領域は .data に確保され初期値として 0 が設定される */
  5
  6    i++;
  7
  8}
        

ファイルのグローバル変数

グローバル変数への static 修飾子は変数のスコープを定義します。 static 指定の変数はスコープがファイル内に制限されます。 static 修飾子を指定しない変数は他のファイルで extern を指定する事で参照する事ができますが、 static 修飾子を指定された変数は extern 指定されても他のファイルからは参照できません。

  1/* ファイル foo.c */
  2static  int     result;         /* 他のファイルから参照不可 */
  3        int     status;         /* 他のファイルから参照可能 */
  4
  5    :
  6
  7/* ファイル bar.c */
  8extern  int     status;         /* foo.c の status を参照 */
  9extern  int     result;         /* foo.c の result は参照できない (通常はコンパイル時にリンクエラーとなる) */
 10
 11    :
        

関数の指定

関数の宣言に static 修飾子を指定した場合はファイルのグローバル変数同様関数のスコープを定義します。 static 修飾子を指定した関数はスコープがファイル内に制限されます。 static 修飾子を指定しない関数は extern 指定する事で他のファイルからも呼び出す事ができますが、 static 修飾子を指定された関数は extern 指定されても他のファイルからは呼び出せません。

まとめ

グローバル変数は値を保持しグローバルに参照できるので便利な変数です。 しかし、多用すると処理全体の見通しが悪くなったり関数の独立性が阻害されてしまうので、 どうしても必要な場合に限ったほうが良いでしょう。

	ローカル変数	グローバル変数
宣言位置	関数 / ブロック内	関数外
スコープ	そのブロック内のみ	ファイル全体 (extern で他ファイルも可)
記憶域期間	自動 (関数終了で消滅)	静的 (プログラム終了まで存在)
確保場所	スタック (static 以外)	データ / BSS 領域
初期値	不定	自動的に 0
主なリスク	スタックオーバーフロー、ダングリングポインタ	名前衝突、意図しない状態共有によるバグ、マルチスレッドでの競合

Cシステムコールとライブラリ関数

C 言語からコールする関数には大きく分けて システムコール と ライブラリ関数 の２種類があります。
どちらも関数呼び出しの見た目をしているため区別がつきにくいのですが、実行時の仕組み、コスト、権限モデルはまったく異なります。
そこで、両者の定義と違いを整理したうえで、システムコール実行時に発生するコンテキストスイッチが OS やアプリの性能にどのような負荷・影響を与えるかを簡単に解説します。

システムコール

システムコールとは、ユーザー空間で動作するプログラムがカーネルの機能を利用するための唯一の手段です。
man 2 open のようにマニュアルのセクション 2 に分類されています。

システムコールには open(2)、read(2)、write(2)、socket(2) などがあります。

CPU には一般に実行できる命令や参照できるメモリ領域に制限のある「ユーザーモード」と、 すべての命令、メモリ空間、I/O ポートにアクセスできる「カーネルモード (特権モード)」の2つの動作モードがあります。 Unix や Linux を始めとするモダンな OS では、アプリケーションプログラムは基本的にユーザーモードで動作していて、 ディスクへの直接アクセスやプロセス管理などの危険な操作はハードウェア的に禁止されています。 そこで、こうした操作が必要な場合は CPU に用意された特別な命令を実行して、 CPU のモードをユーザーモードからカーネルモードへ切り替える必要があります。 Unix や Linux においてこの切り替えを実行するのがシステムコールです。

ライブラリ関数

ライブラリ関数は C 標準ライブラリ (libc) やその他のライブラリが提供するユーザー空間だけで完結する通常の関数です。
man 3 printf のようにマニュアルのセクション3に分類されています。

ライブラリ関数の分類

ライブラリ関数は大きく 2 種類に分類できます。

1. システムコールを呼び出さない純粋なライブラリ関数

strlen(3)、 sin(3) などで、これらは文字列操作や CPU 上での計算処理のみで完結しカーネルには影響しません。

2. 内部でシステムコールをラップしているライブラリ

fopen(3)、fread(3)、printf(3) などで、 これらは最終的に内部で open(2)、read(2)、write(2) といった システムコール発行していますが、 その前後でバッファリング、書式変換、エラー処理の付加などユーザー空間側の便利な処理を行っています。

たとえば fwrite(3) は、呼び出しのたびにシステムコール write(2) を発行するわけではなく、 FILE 構造体が持つユーザー空間のバッファにデータを蓄積して、バッファが一杯になった時、 あるいは fflush(3) や fclose(3) が呼ばれた時にまとめて write(2) システムコールを発行する事で、システムコール呼び出し回数を減らし性能を大きく向上させています。

ライブラリ関数には fopen(3)、fread(3)、fwrite(3) などがあります。

コンテキストスイッチ

コンテキストスイッチとは、CPUがあるコンテキストから別のコンテキストへ切り替える処理全般を指します。

コンテキストスイッチの種類

コンテキストスイッチには大きく分けて 2 種類あります。

1. モード切り替

前述したカーネルモードとユーザーモードの切り替えです。
このタイプのコンテキストスイッチはシステムコール発行や割り込み・例外発生時に起こります。 同一プロセス内での切り替えであり、後述する「プロセス切り替え」よりコストは小さいですがそれなりに負荷やコストがかかります。

2. プロセス切り替え

OS のスケジューラがプロセス/スレッドの実行を中断して別のプロセス/スレッドに実行を渡す処理です。 タイムスライスの満了、I/O 待ちによるブロック、割り込みによるプリエンプションなどで発生します。 ページテーブル (= アドレス空間) 自体が切り替わるためモード切り替えよりもさらにコストが大きくなります。

システムコールは、必ずモード切り替えを伴います。 更にそのシステムコールの処理が入出力など I/O 待ちなどでブロックが発生する場合には さらにプロセス切り替えを誘発することもあります。

コンテキストスイッチのシステム負荷・影響

モード切り替え（システムコール発行）のコスト要因

システムコールを 1 回発行するだけでも以下のような処理コストが発生します。

• レジスタの退避・復元

呼び出し元の CPU レジスタ一式をカーネルスタックへ保存し復帰時に復元します。

• 特権レベルの遷移

CPU 内部の カーネルモードへの遷移、および復帰時のユーザーモードへの遷移で、CPU の内部的な検証・準備処理を伴います。

• パイプラインフラッシュ・投機実行のリセット

モード遷移命令は CPU の命令パイプラインをある程度フラッシュさせ、 投機実行による先読みの効果を失わせます。

他にも TLB (Translation Lookaside Buffer) やキャッシュの汚染(cache pollution)、 セキュリティ機構によるオーバーヘッドなど、様々な影響があります。

これらの要因により、単純なシステムコール 1 回の呼び出しコストは、通常の関数呼び出しと比較して 100 から 1000 倍以上のコストがかかります。

プロセス/スレッド切り替えのコスト要因

システムコールがブロッキング I/O などで待ち状態に入ると、 OS のスケジューラは別のプロセス/スレッドを実行するためにプロセス切り替えを行いますが、 これには前述のモード切り替えのコストに加えて以下のコストが上乗せされます。

• ページテーブルの切り替え

アドレス空間が完全に入れ替わるためTLB 全体が無効化されます。

• スケジューラの実行コスト

次に実行すべきプロセス / スレッドを選択するためのスケジューラの処理が実行されます。

• キャッシュの入れ替え

キャッシュに載っていた前プロセスのデータ・命令が新しいプロセスのアクセスによって徐々に追い出される事により、 キャッシュミス率が一時的に急増して実行速度が低下します。

これらの処理が実行されるため、プロセス切り替えのコストはモード切り替え単体よりもさらに大きくなってしまいます。

頻繁なシステムコールがもたらすシステム全体への影響

例えばアプリケーションが 1 バイトずつ read(2) や write(2) システムコールを呼び出すような設計をすると、 以下のような問題が顕在化します。

• スループットの低下

システムコール自体のオーバーヘッドがボトルネックとなり本来の I/O 帯域を活かせなくなります。

• CPU 使用率の増加

ユーザー時間ではなくシステム時間として CPU 時間が消費されてしまうので、システムの実行時間が高くなります。

• キャッシュ効率の悪化

頻繁なモード切り替えにより CPU キャッシュのヒット率が下がり、 システムコールを呼ばないコードパスの実行速度まで間接的に低下し、結果としてシステム全体のパフォーマンスが低下します。

• スケーラビリティの低下

マルチコア環境では頻繁なシステムコールがカーネル内部の共有データ構造の競合を引き起こすので、 コア数を増やしても性能が線形にスケールしない原因となり得ます。

• レイテンシのジッター増加

割り込みやシステムコールによるコンテキストスイッチが頻発すると、リアルタイム性が求められる処理でジッターが増加します。

まとめ

システムコールはカーネルが提供するハードウェア資源にアクセスするための唯一の方法で、 呼び出しの都度、CPU のコンテキストスイッチが発生します。 一方ライブラリ関数は、多くの場合ユーザー空間だけで完結し、 内部でシステムコールをラップしている場合でもバッファリングなどによって呼び出し回数を抑える設計がされています。 プログラムの要件や仕様などでライブラリ関数では機能が不十分だったり、 特殊な制御が必要な場合以外はライブラリ関数を利用するのが好ましいです。

付録

具体例による比較を実施してみました。実行時間の計測はどちらも Intel CPU 上で稼働する Linux にて実施しました。

システムコールを利用する場合

1 バイト書き込むたびにシステムコール (=モード切り替え) が発生するため、コンテキストスイッチのコストが積み重なり著しく遅くなります。

  1#include <unistd.h>
  2#include <fcntl.h>
  3
  4int main(void)
  5{
  6
  7  int       fd,
  8                i;
  9
 10    if((fd = open("out.txt", O_WRONLY | O_CREAT, 0644)) >= 0){
 11        for(i=0; i<100000; i++)
 12            write(fd, "x", 1);
 13        close(fd);
 14    }
 15    
 16  return 0;
 17
 18}
        

$ time ./syscall

real    0m0.124s
user    0m0.018s
sys     0m0.106s
        

ライブラリ関数を利用する場合

ユーザー空間でバッファリングしてからまとめて write(2) を呼ぶため システムコール発行回数が数百分の一以下に抑えられ高速に動作します。

  1#include <stdio.h>
  2int main(void)
  3{
  4
  5    int     i;
  6  FILE  *fp;
  7
  8    if((fp = fopen("out.txt", "w"))){
  9        for(i=0; i<100000; i++)
 10            fputc('x', fp);
 11        fclose(fp);
 12    }
 13  
 14  return 0;
 15
 16}
        

$ time ./library

real    0m0.003s
user    0m0.001s
sys     0m0.001s
        

今年2回目のキャンプ

今年2回目のキャンプは友人とのデュオキャンプです (今年最初のキャンプは写真を全く撮影していませんでした) 。
今回も TOMOUNT の TC LODGE TENT です。
この時期は幕内で薪ストーブが運用できる TC 素材のテント一択になりますね。

しかし TOMOUNT の TC LODGE TENT はネットを検索してもあまり情報が出てきませんね。
公式サイトにも情報が載っていない気がします。ま、良いんですけどね...

ランチの後は例によって珈琲タイムです。
珈琲のためにキャンプに来ていると言っても過言ではないです (いや、過言ですが)。
自然の中でのんびりと淹れる珈琲の何と美味しい事でしょう。癒やされます。

設営後はかねてから気になっていた 小糸川温泉 に行ってきました。
ぬるぬるで真っ黒の温泉で最初はすこしびっくりしますが入浴するととても気持ちが良い温泉です。
当日はボイラー故障の影響でシャワーやカランのお湯が利用できませんでしたが浸かるにはいい感じです。
休憩室もあり昼食時は簡単な食事も出来る様なので機会があれば食べてみたいです。

この時期のキャンプはテントに籠もって薪ストーブで暖を取っていて 焚き火をしていない事が多いので今回は久々に焚き火をしてみました。
久々ですが焚き火は良いですね。

焚火を楽しんでいると飼い猫 (いついてる猫) のオセロちゃんが向かいのサイトで遊んでいました。
しっぽが可愛かったのでついつい動画におさめてしまったのでこちらもご覧ください。

この日は1月にしては暖かくて昼間は快適でした ( 夜はそれなりに冷えましたけどね)。

年末厳冬キャンプ

例によって柿山田で今年最後のキャンプをしてきました。
ソロでは久々の Fox-Base EVO です。

ランチは手軽にシーズコアのパスタキット (ペペロンチーノ) です。
このシーズコアのキットは必要なものが全て同梱されていて、 水だけでパスタが作れるので忙しい時や手抜きする時に便利です。

夕方で 6 度程度とそこそこの気温です。 さっそく薪ストーブに火を入れてぬくぬくお籠りキャンプの開始です←早すぎ。

アペタイザーとしてマルチグリドルで焼いた焼売をいただきます。 この焼焼売が美味しいんですよね...

メインは薪ストーブを使った鍋料理です。 適当な具材を放り込んだ鍋でよく言えば「ちゃんこ風鍋」でしょうか。
自宅から持参した白菜、水菜、大根、油揚げに スーパーで買った蟹缶、ホタテ缶、そしてたまたま見つけた鶏つくねを放り込んで塩、醤油、酒、みりんで雑に味付けしました。

寒波が襲来している様で夜はどんどん冷えていきます。
おかげで星空はとっても綺麗でした。

明け方の気温はなんと -4度まで下がっていました。 車も真っ白でした。

そんなこんなで今年最後のキャンプは無事に終了しました。

今年も一年ありがとうございました!

TOMOUNT TC LODGE テント初張り

TOMOUNT の TC LODGE テントを入手したので試し張りをかねてキャンプして来ました。
場所? もちろん例によって柿山田ですとも(本当にそこしか行くところがないのか?

このテントの何が素晴らしいかってフレーム1本で自立するロッジ型/パップ型のテントなんです。
しかも燃えづらいポリコットン (TC) 素材で煙突穴まで装備されています (穴は開いてないですがフラップまでは準備されています)。
サイズは FOX-BASE EVO やショウネンテントと比較すると狭めですがソロならば薪ストーブ in しても十分快適に過ごせます。

最大間口は 300cm で奥行きは 237cm なので内部は薪ストーブとコットを設置してもまだ余裕です。
高さはさすがに 130cm と低いのですが割り切って使う分には問題ないですかね。
それよりも総重量が 7.7 Kg と TC テントにしては軽いので設営、撤収、運搬が楽です。 ポール1本で自立できるのもポイント高いです。

ポールは別売りになりますが前幕を跳ね上げる事もでき簡単な雨除けの屋根にになります。
TC 素材なのでこの下で焚き火する事もできると思います (危険なので非推奨です。自己責任でやってくださいね)。

薪ストーブを in すると快適な空間となりました。 前幕を全開にしていると薪ストーブの暖気は殆ど抜けてしまいますが閉めればぬくぬくな快適空間です。

前後左右が開くのでシュルターやタープとしても利用可能です。 ベンチレーションやランタンフック、メッシュタイプの吊り下げ式インナーまで標準で付属して 2万円台なので超お得なテントです。

雨予報の中ソロキャンプを強行しました

この日はは深夜から雨の予報でしたが予約もしちゃったので強行しました。
テントは薪ストーブ in するので DoD のショウネンテント、 撤収はほぼ確実に雨なので撤収時のスペース確保のため久々にヘキサタープを張りました。

11月の声を聞くといよいよ寒さが厳しくなってきます。
そして寒いといえば武井くんの出番! 今年も快適な温もりをよろしくおねがいしますっ!
去年入手できた 501 は燃焼時間が長いので助かります。

よく見るとごちゃごちゃしていますがパッと見はいい感じの写真が撮れました (拡大禁止(笑

夕食は薪ストーブによる簡単調理です。
マルチグリドルでソーセージを焼いたら冬の定番の坦々餃子鍋。 〆は偶然見かけた山頭火のチャーシューを使った坦々風ラーメンです。←これが絶品に美味しいかったです!

夜半過ぎから結構な雨が降ってきました。 タープにも水が大量にたまっています
夜のうちに片付けられる荷物は全て片付けたので朝の片付けは楽な方ですが雨の中の撤収はつかれますね。 (ま、判りきっていた事なんですが...)

柿山田で友人とデュオキャンプ

10月に入りやっと涼しくなってきたのでキャンプシーズン突入です。
例によって友人と柿山田オートキャンプに行ってきました。

この時期は North Face の Lander2 が広くて快適ですね。
例によってサクッと設営を完了させました。

ちなみに同行した友人は ONETIGRIS のパップ(風) テントでした。

設営して多少遅めのランチは肉まんです。 MOOSE ROOM WORKS の戦闘飯盒での蒸したては美味です。

ランチの後は例によってコーヒータイムです。
クラウドファンディングで入手した Snaffkin のドリッパは優秀で、 オールインワンで珈琲以外に紅茶や日本茶でも利用できてコンパクトで軽量、しかもチタン!
ソロでの珈琲タイムはほぼ Snaffkin 一択です。素晴らしい!

しかしいつもいつも同じ事の繰り返しですね...(笑

珈琲タイムの後はキャンプ場のねこ様と遊んだり遊んでもらったり Kindle で読書したりとまったりタイムを過ごします。

夏の間は暑くて焚き火をする気にもならなかったので久々の焚き火タイムです (そもそもキャンプに来ていないですが)
涼しくなってくると焚き火って良いですね。

夕食は炭焼きの豚串と炭焼き(炭火温め) のうなぎをいただきました。
戦闘飯盒の蒸気炊飯で炊いたご飯と相まってとっても美味しゅうございます。

柿山田で友人とデュオキャンプ

少し前になりますが友人とデュオキャンプしてきました。
場所はいつもの柿山田オートキャンプです。

今回は FUTURE FOX の FOX BASE EVO POLY の初張りをしてきました。

主に冬季に薪ストーブ in して使っている FOX BASE EVO は快適なのですが、 TC という素材の特性からとても重く扱いが面倒でした。
そんな事を考えていると FOX BASE EVO の快適性はそのままでポリエステルに素材にした FOX BASE EVO POLY がメーカーでセールしていたのでついつい購入してしまいました。

設営は FOX BASE EVO で何度も経験しているのでお手の物です。
前幕はポリエステル素材の専用品ですがインナーテントや二又ポールなどは共用できます。 冬期は薪ストーブを使う関係でインナーテントは使っていなかったので有効活用ができました。 使い勝手も全く同様です。 設営後とても暑かったので後面を全開にして換気しましたがメッシュインナーに風が通り抜けてとても快適です。

さすがに暑くて焚き火をする気にもならず食事はシングルバーナーで作りました。
今回は純正のサイレンサーを装着したPrimus の Omni Lite Tiで 戦闘飯盒による蒸気炊飯とマルチグリドルを使って食事の支度を簡単に済ませました。

夜になってやっと気温が (ほんの少しだけ) 下がったので珈琲を淹れました。
昼間は暑くて温かい飲み物は無理でした...

覚悟していましたがこの時期はやはり暑いです。昼間の気温は 30 度を超えていました。
これから暫くキャンプはシーズンオフですね。

太陽のたまご♪

実に 11年ぶりの太陽のたまご。

太陽と自然の恵みを今年もとっても美味しくいただきました。

楽々ガーデンでソロキャンプ

梅雨入り & 気温が高くなる前に千葉にある 楽々ガーデン に行って来ました。
初めて訪れるキャンプ場ですが都心から1時間程度の場所にこんなに広大なキャンプ場があるのが驚きです。

今回はオークサイトを利用しましたが 1組限定で完全に独立している素敵なサイトです。 その名の通り大きな楢の木の根元の単独サイトで周囲から若干高くなっています。 微妙にステージの様になっていて微妙な恥ずかしさはあります (笑)

前日の夕方から雨が降っていましたが午前中には雨が止むという天気予報を信じて強行 (でもないか) しました。 結果はまぁまぁ正解で、キャンプ場に到着する頃には雨も殆ど止んでいる状態でした。
薪ストーブの季節も終わったのでテントは The North Face の Lander 2 です。 このテントはポール 2 本で自立し、インナー無しでの使用も可なのでこの時期は重宝します。

たまにポツポツと雨粒が落ちてくる感じもあったので久々に小川張りでの設営です。
タープも含めて設営が終わった頃には雨も完全に止んでいました。 やはり日頃の行いが...

設営が終わったら雄大な景色を愉しみながらノンビリと珈琲タイムです。
天気が悪いという事もあってとても空いていたので気持ち良い時間が過ごせました。

夕食はご飯と炭焼きチキンとハンバーグです。
鶏のモモ肉に塩胡椒だけして炭火で焼くと本当に美味しいです。串打ちしない分だけ焼き鳥よりも手軽なのが良いです。
ハンバーグは近所のスーパーで見かけた「札幌で人気のハンバーグ店」のハンバーグです。
いや、地元だけど聞いた事がないな...地元離れて随分経ってるから知らなくても当然か... などと考えながら食しましたが美味しかったです。

こちらのキャンプ場はいわゆる「高規格なキャンプ場」とは一線を画したキャンプ場です。どちらかと言えばブッシュクラフト寄りな感じです。
設備は何箇所かの水場と簡易トイレですが綺麗に管理されていて不快感は皆無です。
女性専用のエリアもあるのでソロの女性も安心して利用できるかもです。
何よりも都心から 1時間、自宅からでも 2時間程度の所に 60,000 平方メートルの巨大な敷地のキャンプ場があったのが驚きでした。 スタッフの方も丁寧で親切に接して下さいました。 今回、革のグローブを忘れるという失態を犯してしまって割と詰んでいたのですが、備品のグローブを貸して頂けたので事なきを得ました。